Cross-site scripting (XSS) lets attackers inject malicious scripts into web pages. Those scripts run in other users’ browsers and can steal sessions, credentials or data. Attackers can also change what users see. XSS remains common because applications can become vulnerable whenever they display user input without proper protection. Validated testing helps prove whether an application is genuinely vulnerable.
What cross-site scripting is
Cross-site scripting, or XSS, is a web vulnerability that lets an attacker run malicious script code in another user’s browser through a website.
The attacker does not run the code directly on their own machine. Instead, they get the application to deliver the script to another user. The user’s browser then runs the code as part of the trusted website.
This makes XSS dangerous. The script runs within the site’s security context. It can therefore interact with parts of the site that the user can access.
Depending on the application, an attacker could steal session data, capture credentials, access information or change page content.
The main types of XSS
XSS has three main types:
- Stored XSS: The attacker saves malicious script code on the server. The application then sends that code to users who view the affected content.
- Reflected XSS: The attacker sends malicious input through a request. The application reflects that input in its response, which can cause the victim’s browser to run the script.
- DOM-based XSS: The vulnerability exists in client-side code. The browser processes unsafe input and turns it into executable script.
These types differ in how the attacker delivers the script. However, the core problem remains the same. Untrusted input reaches a page in a way that lets the browser treat it as code.
What attackers can achieve with XSS
The impact depends on the application and the user’s access. However, XSS can create serious security problems.
An attacker can target session tokens and potentially hijack a logged-in user’s session. They can also manipulate a page and create a fake login form to capture credentials.
XSS can expose information that the affected user can access. Attackers can also change page content and use a trusted website to deceive users.
The risk becomes greater when the application handles sensitive accounts or valuable data. In those cases, XSS can support account takeover, data theft and other attacks.
Why XSS remains common
Security teams have understood XSS for many years. Yet the vulnerability continues to appear in modern applications.
One reason is the large amount of user input that applications handle. Forms, search fields, comments, profiles and URL parameters can all contain user-controlled data.
Each location creates another opportunity for unsafe input handling.
Developers may protect most areas of an application but miss one field or parameter. That single gap can leave the application vulnerable.
Modern applications also change frequently. New features, integrations and client-side code can introduce new opportunities for XSS. Regular testing therefore remains important even when an application has passed previous security checks.
How to prevent XSS
The main defences against XSS focus on controlling how applications handle untrusted input.
Encode output. Encode user-controlled content before displaying it. This helps the browser treat the content as text instead of executable code.
Validate and sanitise input. Check user input against expected formats and remove unsafe content where appropriate. Input validation should support, rather than replace, safe output handling.
Use a content security policy. A strong content security policy can restrict which scripts a browser can execute. It can reduce the impact of an XSS vulnerability if an attacker bypasses other controls.
Developers should apply these controls consistently across the application. A single unsafe location can create a security gap.
Why validation matters over scanning alone
A vulnerability scanner can identify areas that appear vulnerable to XSS. This makes scanning useful for finding potential issues. However, a scanner cannot always prove that an attacker can exploit the finding in the real application.
Validated testing goes further. It safely tests the suspected weakness and checks whether an attacker can inject and execute a script in a user’s browser.
This creates an important distinction. A scan can identify a possible vulnerability. Validation can confirm whether the vulnerability is genuinely exploitable.
That proof helps security teams focus on the issues that create real risk.
Applications also change over time. Developers add new fields, features and client-side functionality. Those changes can introduce XSS after a previous test found no issues.
For that reason, validation should not be treated as a one-time activity.
To confirm whether your applications are genuinely vulnerable to cross-site scripting, explore our web application security capability. You can also read how continuous service validation keeps security assurance current as applications change.
For technical guidance, see the OWASP cross-site scripting reference.
Frequently asked questions
What is cross-site scripting?
Cross-site scripting, or XSS, is a web vulnerability that lets an attacker run malicious script code in another user’s browser through a website. The script runs within the context of the trusted site, which creates the security risk.
What can attackers do with XSS?
Attackers can steal session tokens, target credentials, access information available to the user and change page content. XSS can therefore support account takeover and data theft.
What are the types of XSS?
The three main types are stored XSS, reflected XSS and DOM-based XSS. Stored XSS saves malicious code on the server. Reflected XSS sends the code through a request and reflects it in a response. DOM-based XSS occurs when client-side code handles unsafe input in the browser.
How do you prevent XSS?
Encode output so browsers treat user content as text. Validate and sanitise input where appropriate. Use a content security policy to limit which scripts a browser can execute. Regular validation also helps confirm that applications remain protected as they change.
