Cross-Site Scripting

Cross-site scripting, commonly abbreviated XSS, exploits the boundary between untrusted data and executable browser content. An attacker supplies content that an application incorporates into a page or processes through an unsafe browser API. When the browser interprets that content as code, it executes with the affected application's origin privileges. Depending on the application's design, this can let the attacker read accessible page data, modify the interface, or send authenticated requests as the victim. The attacker does not need direct access to the cloud account or underlying servers.

Stored XSS occurs when malicious content is persisted, such as in a product review, and later rendered unsafely to other users. Reflected XSS occurs when request data, such as a search parameter, is immediately included in an unsafe response. DOM-based XSS occurs when client-side code moves untrusted data into an executable browser context. These categories can overlap: stored content can also reach an unsafe DOM operation.

Consider a cloud-hosted support portal that stores customer messages in a database. If an administrative page inserts those messages as raw HTML, a malicious message can execute code when an administrator opens the ticket. Database encryption, private subnets, and strict database permissions do not correct this rendering flaw. Similarly, a static application delivered through a content delivery network can remain vulnerable if its JavaScript reads attacker-controlled URL data and assigns it to innerHTML. The hosting platform does not automatically make application code safe.

The primary defense is to keep untrusted data out of executable contexts. Use framework auto-escaping and context-appropriate output encoding, because HTML text, attributes, URLs, and JavaScript have different rules. Prefer safe DOM APIs such as textContent when displaying plain text. Avoid constructing executable code from input. When users genuinely need rich HTML, apply a maintained HTML sanitizer with an explicit allowlist rather than attempting to remove suspicious strings with regular expressions. Input validation is useful for enforcing business rules, but it does not replace safe output handling.

Content Security Policy provides defense in depth by restricting script execution and other browser behavior. A carefully designed policy using nonces or hashes can reduce exploitability, but broad script allowances and unsafe exceptions weaken it. Deploying a strict policy may require application changes and testing; report-only mode can help identify compatibility problems before enforcement. HttpOnly cookies prevent scripts from directly reading those cookies, but injected code may still make authenticated requests. Secure cookies and HTTPS protect transport-related properties, not unsafe rendering.

In cloud architectures, a web application firewall can inspect supported HTTP request components and block recognizable XSS payloads before they reach the application. This is useful as an additional control or temporary mitigation, but inspection limits, false positives, and evasive payloads require tuning. URL fragments are not sent in HTTP requests, so a WAF cannot inspect a malicious fragment that triggers a browser-only DOM flaw. Review changes in count mode where appropriate, monitor matches, and fix the underlying application vulnerability.

For architecture exam questions, distinguish the threat from its mitigation layer. XSS is an application-layer browser execution problem, whereas SQL injection targets database query interpretation and DDoS targets availability. Network security groups and network ACLs do not analyze HTML or JavaScript payloads, and DDoS protection does not replace XSS controls. The practical design combines secure application rendering, browser security policies, appropriately configured application-layer filtering, and security testing.