Software Testing Trends LogoSoftware Testing Trends

Cross Site Scripting (XSS) Explained

Understand how XSS works, why it's dangerous, and how to prevent it.

XSS stands for Cross Site Scripting.

It is a web security vulnerability where an attacker injects malicious JavaScript into a trusted website, and that script executes in other users’ browsers.

Instead of attacking the server directly, XSS targets the users of the application.

What Actually Happens

  1. An application accepts user input.
  2. The input is not properly validated or escaped.
  3. The input gets rendered in the browser.
  4. Malicious JavaScript executes in the victim’s session.

Example:

If a comment field allows this input:

<script>alert('Hacked')</script>

and the app renders it directly, the browser executes the script.

Why XSS Is Dangerous

An attacker can:

  • Steal session cookies
  • Hijack authenticated sessions
  • Perform actions as the victim
  • Redirect users to malicious sites
  • Modify page content
  • Capture keystrokes

Types of XSS

1. Stored XSS

Malicious script is saved in the database and served to users later. Example: comment sections, user profiles.

2. Reflected XSS

Script is reflected in the response immediately. Often through URL parameters.

Example:

example.com/search?q=<script>...</script>

3. DOM Based XSS

The vulnerability exists in client side JavaScript. The server response is safe, but browser-side code injects unsafe data into the DOM.

How to Prevent XSS

1. Output Encoding

Escape user input before rendering:

  • HTML encoding
  • Attribute encoding
  • JavaScript encoding

2. Input Validation

Reject unexpected input formats.

3. Use Framework Protections

Modern frameworks like React and Angular auto escape by default.

4. Content Security Policy (CSP)

Restricts what scripts can run.

5. HttpOnly Cookies

Prevents JavaScript from reading session cookies.

Security Classification

XSS is part of the OWASP Top 10 web application security risks.

XSS Testing Checklist

This checklist is aligned with guidance from OWASP and tailored for web application testing.

1. Input Surface Mapping

Identify every place where user controlled input enters the system:

User Inputs

  • Text fields
  • Search bars
  • Comment sections
  • Profile fields
  • Feedback forms
  • File names
  • Rich text editors

URL Based Inputs

  • Query parameters
  • Path parameters
  • Hash fragments

Headers

  • User Agent
  • Referer
  • Custom headers

Stored Data Sources

  • Database content
  • Admin panels
  • Imported CSV or JSON
  • Third party integrations

2. Reflected XSS Testing

Test inputs that are immediately returned in the response.

Basic Payload

<script>alert(1)</script>

Attribute Injection

" onmouseover="alert(1)

HTML Injection

<img src=x onerror=alert(1)>

Test Cases

  • Inject into search queries
  • Inject into error messages
  • Inject into form validation messages
  • Inject into redirect URLs

Verify:

  • Is input reflected?
  • Is it encoded?
  • Does JavaScript execute?

3. Stored XSS Testing

Test persistent inputs:

Areas to Test

  • Comments
  • User bios
  • Product reviews
  • Chat messages
  • Admin created content

Validation

  1. Inject payload.
  2. Log out.
  3. Log in as another user.
  4. Check if script executes.

Critical for:

  • Privilege escalation scenarios
  • Admin panel exposure

4. DOM Based XSS Testing

Focus on client side rendering.

Look For

  • innerHTML usage
  • document.write
  • eval
  • dangerouslySetInnerHTML in React
  • jQuery html()

Test Payload via URL

#<img src=x onerror=alert(1)>

Use browser DevTools:

  • Inspect DOM
  • Check if payload is inserted dynamically

5. Context Based Testing

XSS depends on context. Test injection in:

HTML Context

<script>alert(1)</script>

Attribute Context

" autofocus onfocus=alert(1) "

JavaScript Context

';alert(1);//

URL Context

javascript:alert(1)

6. Encoding Validation

Verify:

  • < is encoded to &lt;
  • > is encoded to &gt;
  • " is encoded to &quot;
  • ' is encoded to &#39;

Confirm encoding matches context.

Incorrect encoding can still allow bypass.

7. CSP Validation

Check if Content Security Policy is implemented:

  • Are inline scripts blocked?
  • Are unsafe eval rules disabled?
  • Is only trusted domain allowed?

Use browser console to inspect CSP headers.

8. Cookie Security

Check:

  • HttpOnly flag enabled
  • Secure flag enabled
  • SameSite attribute set

Attempt:

document.cookie

Ensure session cookie is not accessible.

9. Authentication Bypass Checks

Test whether XSS can:

  • Steal JWT tokens
  • Perform authenticated actions
  • Modify role values
  • Call privileged APIs

Simulate real attacker goals, not just alert popups.

10. Regression Strategy

Add automated security tests:

  • Dynamic scanning tools
  • CI pipeline scanning
  • Security unit tests for encoding functions

Integrate checks into:

  • Pull requests
  • Nightly builds
  • Pre production validation

11. Risk Prioritization Matrix

Prioritize XSS issues based on:

  • Is it stored or reflected?
  • Does it affect authenticated users?
  • Does it impact admin accounts?
  • Can it steal tokens?
  • Can it perform state changing requests?

Stored XSS impacting admin = Critical.

12. Reporting Template for QA

When reporting:

  • Injection point
  • Payload used
  • Execution proof
  • Impact analysis
  • Screenshots or video
  • Browser used
  • Authentication state

Avoid reporting only alert popups. Always describe business impact.

Browse All Resources