What Is Cross-Site Scripting (XSS)?

Cross-Site Scripting (XSS) is a web application vulnerability that allows an attacker to inject malicious content, typically JavaScript, into a web page that is viewed by another user.

Depending on the type of XSS and the application's functionality, an attacker may be able to execute code in another user's browser, access sensitive information, manipulate web pages or perform actions on behalf of the victim.

XSS remains an important web application security issue because applications frequently accept, process and display user-controlled content.

How Does XSS Work?

Web applications often need to display information supplied by users.

For example, a website might allow users to:

• Leave comments
• Update their profile
• Send messages
• Upload content
• Submit support requests
• Enter information into forms

The application may then display that information to other users.

If the application does not correctly handle untrusted content before displaying it in a browser, an attacker may be able to inject content that the browser interprets as executable code.

The key issue is that the browser cannot reliably distinguish between legitimate application content and malicious content inserted by an attacker.

A Simple Example

Imagine a website that allows users to leave comments.

A legitimate comment might be:

Great article!

If the application simply places user-supplied content into the resulting HTML without appropriate output encoding, an attacker could attempt to submit content designed to execute in another user's browser.

The exact payload used during testing depends on the context in which the input is reflected, but the underlying problem is the same:

Untrusted data is being treated as executable content.

A secure application should ensure that user-controlled input is correctly handled according to the context in which it is being displayed.

What Can an XSS Vulnerability Do?

The potential impact depends on the application's functionality and the type of XSS.

An attacker may potentially be able to:

• Modify the appearance of a web page
• Display misleading content
• Capture information entered into a page
• Perform actions using the victim's privileges
• Access information available to JavaScript in the application's context
• Redirect users to malicious content
• Target administrators or privileged users

For example, an XSS vulnerability in an administrative interface could be particularly serious if an attacker can cause a privileged administrator to interact with malicious content.

The vulnerability therefore isn't necessarily limited to affecting the person who submitted the malicious input.

The Three Main Types of XSS

XSS is commonly divided into three categories.

Stored XSS

Stored XSS occurs when malicious content is stored by the application and subsequently displayed to other users.

For example, an attacker might submit malicious content as part of a profile, comment or message.

When another user views the affected page, the malicious content is retrieved from the application and executed in their browser.

Stored XSS can be particularly serious because the attacker may only need to submit the malicious content once for multiple users to encounter it.

Reflected XSS

Reflected XSS occurs when malicious input is immediately returned by the application in its response.

A common example is an application that takes a value from a URL parameter and displays it on a page without correctly encoding it.

An attacker may construct a malicious URL and attempt to persuade another user to visit it.

The malicious content is then reflected by the application and processed by the victim's browser.

DOM-Based XSS

DOM-based XSS occurs when client-side JavaScript processes attacker-controlled data in an unsafe way.

The vulnerability may exist entirely within the browser-side code rather than being directly reflected by the server's response.

For example, JavaScript might take data from a URL and insert it into the page using an unsafe DOM operation.

DOM-based XSS can therefore require detailed analysis of the application's JavaScript rather than simply examining server responses.

Why Is XSS Dangerous?

The impact of XSS depends on the application's security architecture and what the affected user can access.

A vulnerability affecting a standard public page may have limited consequences.

However, XSS affecting an authenticated application or administrative interface can be significantly more serious.

An attacker may potentially use XSS to target users with higher privileges and perform actions within the application using their existing permissions.

This makes the context of the vulnerability extremely important when assessing its severity.

How Can Organisations Prevent XSS?

The primary defence against XSS is to ensure that untrusted data is correctly handled before it is inserted into a web page.

Important measures include:

• Use context-appropriate output encoding
• Validate input where appropriate
• Avoid unsafe DOM manipulation
• Use secure development frameworks and libraries
• Implement an appropriate Content Security Policy (CSP)
• Use secure cookie settings
• Keep JavaScript dependencies up to date
• Avoid inserting untrusted content directly into HTML

Developers should be particularly careful about where user-controlled data is inserted.

HTML, JavaScript, CSS, URL and attribute contexts can all have different security requirements.

Simply filtering a few characters is therefore unlikely to provide reliable protection.

What About Content Security Policy?

A Content Security Policy (CSP) can provide an additional layer of protection against XSS.

CSP allows an organisation to define which types of content a browser is permitted to load or execute.

A properly designed policy can make exploitation more difficult even if an XSS vulnerability exists.

However, CSP should be treated as defence in depth, not as a replacement for fixing the underlying vulnerability.

The application should still correctly encode and handle untrusted data.

Can Automated Scanners Find XSS?

Automated vulnerability scanners can be effective at identifying many common XSS vulnerabilities.

They can test large numbers of parameters and inputs quickly and can be particularly useful for identifying obvious reflected XSS issues.

However, automated scanning has limitations.

Complex applications may contain:

• Client-side JavaScript frameworks
• Dynamic content
• Multiple authentication states
• Custom input processing
• Complex DOM interactions
• Content sanitisation mechanisms

These can make some XSS vulnerabilities difficult to identify automatically.

Manual testing can help determine how data flows through the application and whether seemingly harmless input can ultimately reach a dangerous browser context.

XSS and Web Application Penetration Testing

A comprehensive web application penetration test should consider XSS across both authenticated and unauthenticated functionality.

A penetration tester can examine how user-controlled data is:

1. Submitted to the application.
2. Processed by the server.
3. Stored or reflected.
4. Returned to the browser.
5. Handled by client-side JavaScript.

Testing can also consider the application's different user roles.

For example, an XSS vulnerability that can be triggered by a standard user but executes when an administrator views the affected content may have significantly greater impact than the initial functionality suggests.

Why Manual Testing Still Matters

Finding XSS isn't always as simple as submitting a known payload and seeing whether an alert appears.

A tester needs to understand where the input is being placed and how the browser interprets it.

An input that is safely displayed in one part of an application may be dangerous in another context.

Manual testing can therefore complement automated scanning by examining the application's behaviour, business logic and client-side functionality in greater depth.

Conclusion

Cross-Site Scripting occurs when an application allows untrusted content to be interpreted as executable content in another user's browser.

XSS can range from relatively limited website manipulation to serious attacks against authenticated or privileged users.

Secure output encoding, safe handling of DOM content and appropriate defence-in-depth measures such as Content Security Policy can significantly reduce the risk.

Regular web application penetration testing can provide additional assurance by identifying XSS vulnerabilities and testing how they could actually be exploited within the context of the application.