Cross-Site Scripting and How AWS WAF Helps Protect Applications

Cross-site scripting (XSS) is a common web application security vulnerability that can allow an attacker to inject malicious content into a web page that is then executed in another user's browser.

For organisations running customer-facing applications, protecting against XSS is an important part of application security. However, detecting XSS is not always straightforward. Legitimate application requests can sometimes contain patterns that resemble malicious input, particularly when applications handle files, structured data or complex request payloads.

This is where a Web Application Firewall (WAF) can provide an additional layer of protection.

If you missed Part 1, Fine-Tuning AWS WAF Without Compromising Security, we looked at how legitimate customer activity can trigger WAF rate-limiting rules and how to tune them based on real-world usage.

What is Cross-Site Scripting?

Cross-site scripting occurs when an application accepts untrusted input and subsequently renders it in a way that allows executable code, typically JavaScript, to run in a user's browser.

For example, an application might accept a value such as:

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

If that input is not properly validated or encoded before being returned to a user's browser, the browser may interpret it as executable code rather than ordinary text.

An attacker could potentially use this to:

• Steal session information
• Access information available to the user's browser
• Modify content displayed to users
• Perform actions on behalf of an authenticated user
• Redirect users to malicious websites
• Deliver further malicious content

The exact impact depends on the application and how the vulnerability can be exploited.

Where a WAF Fits In

Application security should not rely on a single security control. Input validation, output encoding, secure development practices and application-level security controls should all form part of the overall approach.

A WAF provides an additional layer by inspecting HTTP requests before they reach the application.

AWS WAF includes managed rules that can identify request patterns associated with common web attacks, including XSS. These rules analyse elements of incoming requests and can block requests that match known attack patterns.

This can be particularly useful for applications where it is not practical to rely entirely on application-level validation to identify malicious requests.

The important distinction is that a WAF is looking at the characteristics of a request, rather than understanding the user's intent.

A malicious request and a legitimate request can therefore sometimes contain similar patterns.

When Legitimate Traffic Looks Suspicious

This is one of the operational challenges of using WAF protection.

An application may legitimately accept content that contains strings, characters or structures that resemble attack payloads. File uploads are one example.

In one customer environment, a legitimate document upload triggered an AWS WAF managed XSS rule. The document had been converted from PDF into another format, resulting in content within the request that matched a pattern associated with cross-site scripting.

From the WAF's perspective, the request contained characteristics that warranted inspection or blocking.

From the application's perspective, it was a completely legitimate customer workflow.

This is why WAF configuration should not be treated as a set-and-forget exercise.

Investigating WAF Blocks

When a legitimate request is blocked, the first step should be understanding why the WAF considered the request suspicious.

AWS WAF logging provides useful information for this investigation, including:

• The request that was inspected
• The rule that matched
• The action taken by the WAF
• The request URI
• The HTTP method
• Details of the terminating rule
• The source IP and other request metadata

This information can be used to establish whether a request represents a genuine attack, an unexpected usage pattern or a false positive.

For example, AWS WAF logs can be queried to identify requests blocked by a particular rule or to investigate activity against a specific application endpoint.

-- Example query structure for investigating blocked WAF requests

fields @timestamp, action, httpRequest.clientIp, httpRequest.uri, terminatingRuleId

| filter action = "BLOCK"

| sort @timestamp desc

| limit 100

The exact query will depend on how AWS WAF logging is being delivered and queried within the environment, but the principle is the same: use the available telemetry to understand what the WAF is seeing before changing the security configuration.

Handling False Positives

If an investigation confirms that a request is legitimate, the answer should not automatically be to disable the relevant WAF protection.

Instead, consider:

1. Can the application behaviour be changed?
   If the application can safely validate, encode or restructure the input, this may remove the underlying cause.
2. Can the WAF rule be scoped more precisely?
   A rule may be adjusted or overridden for a specific use case rather than across the entire application.
3. Can an exception be limited to a specific endpoint or request component?
   Narrow exceptions reduce the risk of unintentionally weakening protection elsewhere.
4. Is the exception still appropriate over time?
   WAF exclusions should be reviewed as the application and its traffic patterns change.

The goal should always be to make the smallest change necessary to support legitimate application behaviour while retaining as much protection as possible.

What to Look Out For

When operating AWS WAF, there are several signals worth monitoring.

Unexpected increases in blocked requests: A sudden increase in requests blocked by an XSS rule may indicate an attack, a new application behaviour or a false positive.

Blocks concentrated on one endpoint: If blocks are consistently associated with a particular endpoint, investigate what that endpoint accepts and how its requests are structured.

Legitimate workflows failing: File uploads, search functionality, rich text fields and APIs accepting structured data can sometimes generate requests that look unusual to security rules.

Changes after application releases: A new application feature can introduce previously unseen traffic patterns. WAF rules that worked without issue before a release may begin blocking legitimate requests afterwards.

Changes in managed rules: Managed WAF rules can evolve as new threats and detection techniques are introduced. Existing application traffic should therefore be monitored when rule groups are updated.

Security and Observability Need to Work Together

The practical lesson is that WAF protection and observability are closely connected.

A WAF can provide valuable protection against attacks such as XSS, but when something is blocked, security teams need sufficient visibility to understand the decision being made.

Without logs and appropriate monitoring, a blocked request can simply appear to the user as an application error.

With the right observability in place, the team can determine:

What happened → Which rule triggered → What traffic caused it → Whether it was malicious → What action is appropriate

This allows security controls to be tuned based on evidence rather than assumptions.

Conclusion

Cross-site scripting remains an important web application security risk, and AWS WAF can provide a valuable additional layer of defence.

But effective WAF management is about more than enabling managed rules. Applications evolve, traffic changes and legitimate workloads can sometimes resemble malicious activity.

The answer is not to weaken security controls whenever something is blocked. It is to understand what the WAF detected, investigate the underlying traffic and make the smallest appropriate change when legitimate behaviour has been identified.

That is the broader lesson from this series: security controls work best when they are supported by observability and an understanding of real application behaviour.

At Mesoform, we build secure, observable cloud platforms that evolve with your applications. If your WAF is blocking legitimate traffic, contact us to investigate and tune your rules without compromising protection.