Preventing XSS (Cross-Site Scripting) in PHP and Node.js

Cross-site scripting (XSS) lets an attacker run their JavaScript in your visitors' browsers, on your domain, with your users' sessions. It is one of the most common web application flaws, and OWASP groups it under Injection in its Top 10. This guide covers the three kinds of XSS, the output-encoding rules that stop them in PHP and Node.js, and how a Content Security Policy catches what slips through.

1. What XSS is and what it can do

XSS happens when user-supplied content reaches a page's HTML, attributes or scripts without being encoded for that context, so the browser runs it as code. One working XSS on a site with logins can:

• act as the logged-in user: change their email, place orders, delete content;
• read anything the user can see, including private messages and admin screens;
• steal session cookies, unless they are marked HttpOnly;
• redirect visitors to phishing pages or malware.

XSS and SQL injection share a root cause, mixing code with data, but they need different defences at different layers. For the database side, see Preventing SQL injection in PHP and Node.js.

2. The three types

A reflected example in PHP:

echo "Search results for: " . $_GET['q'];   // vulnerable

A DOM-based example in JavaScript:

document.getElementById('greeting').innerHTML = 'Hello ' + location.hash.slice(1); // vulnerable

The fix for the DOM case is to use textContent instead of innerHTML whenever you are inserting text.

3. Defence 1: encode output for its context

This is the primary defence. Each output context needs its own encoding:

PHP

function e(string $v): string {
    return htmlspecialchars($v, ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5, 'UTF-8');
}

echo '<a href="' . e($safeUrl) . '">' . e($userName) . '</a>';

Since PHP 8.1, htmlspecialchars encodes both single and double quotes by default, but passing the flags and 'UTF-8' explicitly keeps the code safe and clear on any version. Template engines do this for you:

• Blade (Laravel): {{ $var }} escapes; {!! $var !!} does not. Audit every {!! !!}.
• Twig: {{ var }} escapes when autoescape is on (the default); |raw does not.
• WordPress: esc_html() for text, esc_attr() for attributes, esc_url() for links, wp_kses() to allow a limited set of tags.

Node.js

• React and Next.js: JSX escapes values automatically. The escape hatch is dangerouslySetInnerHTML; pass it only sanitised HTML. Also validate URLs you put in href, because a javascript: URL is not fixed by escaping.
• Vue: {{ }} and v-text are safe; v-html is not.
• EJS: <%= %> escapes; <%- %> does not.
• Handlebars: {{ }} escapes; {{{ }}} does not.
• Pug: #{} escapes; !{} does not.

Every mainstream engine is safe by default with an explicit opt-out. Search your code base for the opt-out forms: that is where XSS lives. Avoid building HTML with string concatenation; if you must, escape with a small, tested helper and keep it in one place.

4. Sanitise HTML you have to accept

Rich-text fields (blog posts, formatted comments, WYSIWYG editors such as TinyMCE or CKEditor) produce HTML, which escaping would destroy. Clean it with an allow-list sanitiser instead:

• PHP: HTML Purifier.
• JavaScript: DOMPurify (in the browser, or on the server with a DOM implementation such as jsdom), or sanitize-html.

import DOMPurify from 'dompurify';
const clean = DOMPurify.sanitize(userHtml);

Sanitise on the server before storing, and treat anything from the editor as untrusted. If you accept Markdown, sanitise the HTML the Markdown library produces: current Markdown libraries don't sanitise by themselves.

5. Defence 2: a Content Security Policy

A Content Security Policy (CSP) tells the browser which scripts may run. With a strict policy, an injected script tag or inline event handler is blocked even if an escape was missed.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-RANDOM'; object-src 'none'; base-uri 'self'

Generate a new random nonce for every response and add it as a nonce attribute on each legitimate script tag. Avoid 'unsafe-inline' in script-src, which cancels most of the protection. Deploy it first as Content-Security-Policy-Report-Only, fix what it reports, then enforce it. For DOM XSS, modern browsers also support Trusted Types (require-trusted-types-for 'script'), which blocks raw string assignments to sinks such as innerHTML.

The old X-XSS-Protection header is obsolete; leave it out or set it to 0. The full header set, with Apache, nginx and Node.js examples, is in Security headers explained: CSP and HSTS.

6. Supporting layers

• Input validation. Reject what can't be valid early: a username of letters, digits and underscores; an email that parses as an email; an integer in range. Use Laravel's validator or a schema library such as zod. It reduces risk but never replaces output encoding.
• Cookies. Set session cookies HttpOnly, Secure and SameSite=Lax (or Strict). HttpOnly stops scripts reading the cookie; XSS can still act as the user, so it limits the damage rather than preventing it.
• No eval. Never pass user input to eval(), new Function() or setTimeout with a string. Use JSON.parse() for data.

7. Test for XSS

On a staging copy of your own site, enter harmless payloads like these into every field, URL parameter and header you reflect:

"><img src=x onerror=alert(1)>
<svg onload=alert(1)>
javascript:alert(1)

If an alert box appears, you have XSS; if the text shows literally, encoding is working.

Tools that help:

• Dynamic scanners: OWASP ZAP (free) and Burp Suite Professional. Burp's free Community edition has no automated scanner, but is useful for manual testing.
• Static analysis: Psalm's taint analysis for PHP, Semgrep rules for PHP and JavaScript, and eslint-plugin-security for Node.js.

Test only sites you own or have written permission to test.

8. Running this on Domain India

Our cPanel servers run Imunify360 with its full ModSecurity ruleset, measured in September 2026, which blocks many common attack requests before they reach PHP. It may also block your own test payloads, so a test that "passes" on the live site can hide a real bug; test on staging and in code review too. A firewall is a safety net for known patterns, not a replacement for encoding in your code.

• Security headers: on cPanel and DirectAdmin hosting, set CSP and the other headers in .htaccess with Header always set; mod_headers is loaded on both.
• Node.js apps: run on shared cPanel hosting through Setup Node.js App, or on the App Platform; the same encoding rules apply.
• If a site is already compromised: follow the security checklist for a hacked or defaced website.

For the wider picture, read OWASP Top 10: practical defence for PHP and Node.js and CSRF tokens deep dive.

Ready to harden your site? Add the headers from Security headers explained, then review your templates for raw-output forms. To host PHP or WordPress sites, compare cPanel hosting; for Node.js apps, see the App Platform.