Cross-site scripting (XSS)

Cross-site scripting (XSS) is a flaw where a website shows content that a visitor supplied, such as a comment, a search term or a profile field, without making it safe first. If that content contains a script, the visitor's browser runs it as if it came from your site.

Because the script runs with your site's permissions in that browser, it can read what the page can read, act as the visitor, or change what the page shows.

1. The attacker finds a place where input appears in a page: a search results page, a comment, a username, an error message.
2. They submit a small script, or build a link that carries it in the address (reflected XSS), or save it so it is shown to everyone who opens the page (stored XSS).
3. A visitor opens the page or the link, and their browser runs the script.
4. The script can then steal data the page can reach, perform actions as that visitor, or show fake content such as a counterfeit login box.

• Requests whose URL contains script tags, javascript: links or attributes such as onerror= and onload=.
• User-generated content that contains HTML tags it should not.
• Visitors reporting strange pop-ups, redirects or login boxes on your site.
• Unexpected outbound requests from your pages to unfamiliar domains.

• Theft of session data and account takeover.
• Fake forms that collect passwords or payment details from your own visitors.
• Defacement or malicious redirects that damage trust in your brand.
• Spread of malware through your pages.

• Escape (encode) all user-supplied content when you put it in a page. Modern frameworks do this by default; be careful with anything that inserts raw HTML.
• If you must allow HTML from users, clean it with a well-maintained sanitiser library.
• Send a Content-Security-Policy header that limits where scripts can come from.
• Mark session cookies HttpOnly and Secure, and use SameSite.
• Review every field whose content other people will see.
• Check your own headers for free with the Rakshak website security scanner.

Not sure how your own site looks from outside? Run the free website security scanner.

Rakshak checks the address each visitor requests, meaning the path and the query string after decoding it, for script-injection patterns.

Examples of what it looks for: script tags, javascript: links, inline event handlers such as onerror= or onload=, and tags such as iframe, svg, img or body with an event handler attached.

• Every detection creates an alert in your Rakshak dashboard with the IP address, the request that triggered it, the severity and the time.
• If you have connected Telegram, Rakshak also sends you a message. You choose which severities you want to be told about.
• Repeated alerts of the same type from the same IP address are grouped for ten minutes, so you are not flooded with duplicates.
• Cross-site scripting (XSS) is a critical-severity detection, so Rakshak automatically adds the offending IP address to your blocklist. With the Rakshak server middleware installed, that visitor then sees an "Access denied" page instead of your website.
• Blocking needs the Rakshak server middleware on your website. The lightweight browser snippet can detect and alert, but a browser script cannot block a visitor.

A website has a search page that prints the search term back on the results page. An attacker builds a link that carries a script as the search term and sends it to the site's users.

When the link is requested, Rakshak sees the script tag in the address, raises a critical XSS alert and (with the middleware installed) blocks that IP address.

The owner then fixes the search page so it encodes what it prints, and adds a Content-Security-Policy so a similar mistake elsewhere is harder to exploit.

GET /search?q=<script>alert(1)</script>

What is the difference between reflected and stored XSS?

In reflected XSS the script travels in a link and is shown straight back by the page. In stored XSS the script is saved, for example in a comment, and shown to everyone who opens that page. Stored attacks usually arrive in form data, which URL-based detection does not see.

Does Rakshak protect my visitors' browsers from XSS?

No. Rakshak detects XSS attempts that appear in the requested URL, alerts you, and can block the source IP. Protecting browsers needs output encoding and a Content-Security-Policy on your website.

Does a Content-Security-Policy fully prevent XSS?

A strict policy makes injected scripts much harder to run, but it is a second layer. Correct output encoding is still the main fix.

Are cookies safe if I use HttpOnly?

HttpOnly stops scripts from reading the cookie, which limits one common XSS goal. A script can still act on the page, so it does not make XSS harmless.

How can I check my security headers?

Use the free Rakshak website security scanner. It checks your homepage for a Content-Security-Policy, cookie flags and other headers, and explains how to fix each finding.