How do you test for SQL injection and cross-site scripting (XSS)?

SQL injection and XSS are both injection flaws: the application takes untrusted input and lets it become part of something that gets executed, a SQL statement on the server or HTML and JavaScript in a browser. Testing for them means finding every place input enters and every place it comes back out.

Ground rules first

Only run these tests against environments you are authorised to test, ideally a dedicated test or staging environment. Automated tools like sqlmap can modify or delete data, so agree scope with the owning team.

SQL injection

Where: any parameter that may reach a query, including search boxes, filters, sort fields (?sort=name), IDs, headers and JSON body fields.

Probes and signals:

• A single quote ' or " in a field. A 500 error or a database error message in the response is a strong signal that input is concatenated into SQL.
• Boolean pairs: ?id=10 AND 1=1 versus ?id=10 AND 1=2. If the responses differ in a way the input should not explain, the condition is being evaluated.
• Time-based payloads (database-specific, for example pg_sleep(5) in PostgreSQL) for blind injection where nothing visible changes but the response is delayed.
• Sort and column parameters deserve extra attention because they cannot be bound as parameters and are often built with string concatenation.

Correct fix to verify in code review: parameterized queries or prepared statements, allow-lists for identifiers like sort columns, and least-privilege database accounts.

// Vulnerable
String sql = "SELECT * FROM users WHERE email = '" + email + "'";

// Safe
PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE email = ?");
ps.setString(1, email);

Cross-site scripting

There are three kinds:

• Reflected: input in the request is echoed into the response, for example a search term.
• Stored: input is saved (a comment, a display name) and rendered to other users later. This is usually the most serious.
• DOM-based: client-side JavaScript writes input from the URL or storage into the page via sinks like innerHTML.

Probes: inject payloads such as <img src=x onerror=alert(1)> or "><svg onload=alert(1)> into every field, then visit every page where the value is displayed, including admin views, emails and exports. Do not rely only on <script> tags, which many frameworks block. Inspect the rendered HTML: the value should appear encoded (<img ...) and never execute.

Correct fix: contextual output encoding (frameworks like React and Angular encode by default, so look for escape hatches such as dangerouslySetInnerHTML or bypassSecurityTrustHtml), sanitising rich text with a vetted library, a Content Security Policy as defence in depth, and HttpOnly session cookies so a successful XSS cannot read them.

Making it repeatable

• Add a small set of injection payloads to your API and UI test data so that every form and endpoint gets them in regression.
• Run a DAST scanner such as OWASP ZAP against staging in the pipeline.
• Rely on SAST in pull requests to catch string-built queries before they ship.

What interviewers look for

• You explain the shared root cause, not just payload lists.
• You know the different XSS types and that stored XSS must be checked where data is displayed, not where it is entered.
• You can name the real fix, so your bug reports are actionable.
• You mention authorisation and safe scope before running tools.

Common mistakes

• Treating client-side validation as protection.
• Testing only with <script>alert(1)</script> and declaring the field safe.