Preventing Cross-Site Scripting and Cross-Site Request Forgery in PHP

Cross-Site Scripting and Cross-Site Request Forgery exploit different weaknesses. Each needs its own defense, built into the application's output pipeline and state-change workflow. Treat them as one problem and your PHP application stays vulnerable on the side you ignored.

Separate the two concerns completely. For XSS, use output encoding tuned to the exact context where data lands, backed by a Content-Security-Policy header that blocks what slips through. For CSRF, tie a token to the PHP session and verify it on every state-changing request. Reinforce that with cookie flags that limit how browsers send session identifiers. A PHP application that does not encode output on the way out and does not verify a token on the way in is open to attack, no matter how recent its framework version.

Cross-Site Scripting fires when untrusted data reaches a browser and the browser treats it as code instead of text. In PHP, call htmlspecialchars() with the correct flags at the point where data leaves the application and enters HTML. The function converts characters that have special meaning in HTML, <, >, &, ", and single quotes when the flag is set, into their corresponding HTML entities. The browser renders them as visible characters, not as markup or script.

The flags that matter are ENT_QUOTES and a strict UTF-8 character set. ENT_QUOTES encodes both double and single quotes. This closes off attribute injection whether the developer used single or double quotes around the attribute value. The UTF-8 flag tells PHP to treat the string as UTF-8 and to return an empty string if the input contains an invalid byte sequence. That prevents a multibyte attack that could bypass the encoding. A call that omits ENT_QUOTES leaves single-quoted attributes open. A call that omits UTF-8 can be tricked by a crafted byte sequence the function does not recognise as a special character.

Encoding for the Right Output Context

The output context rule is simple but frequently broken. Data landing inside a JavaScript block needs JavaScript encoding. Data landing inside a URL needs URL encoding. Data landing inside HTML needs HTML entity encoding. A common failure is passing a string through htmlspecialchars() and then dropping it into an inline <script> tag. The HTML entities that protect against HTML injection do nothing inside a JavaScript string. A backslash, a quote, or a closing script tag can break the string and inject code.

For JavaScript contexts, avoid inline scripts entirely. Serve data through data- attributes or AJAX endpoints where the client reads JSON. When inline data is unavoidable, encode with json_encode() and set the JSON_HEX_TAG, JSON_HEX_AMP, JSON_HEX_APOS, and JSON_HEX_QUOT flags. For URL contexts, rawurlencode() handles characters not allowed in a URL path or query string. The OWASP Cheat Sheet on XSS prevention maps every output context to the correct encoder. Commit that mapping to memory.

What Goes Wrong on Shared Hosting

South Florida shared-hosting environments often run PHP applications on cPanel where the MultiPHP INI editor controls settings per directory. The display_errors directive is sometimes left on in staging. A stack trace that reveals file paths and query fragments is itself an XSS vector if an attacker can trigger an error and the output is not suppressed. Set display_errors = Off and log_errors = On in the production php.ini. Use a custom error handler that returns a generic message to the browser while logging the full trace to a file the web server cannot serve.

A Content-Security-Policy header is a browser-side enforcement that limits which scripts, styles, and other resources a page can load. It acts as a second defense layer. Even when output encoding fails and a script tag slips through, the CSP header can block its execution. Send the header as an HTTP response header from PHP, either through the web server configuration or by calling header() before any output.

The most effective CSP directive for XSS mitigation is script-src. A policy that disallows inline scripts and permits scripts only from a known list of origins removes the attacker's ability to execute injected code, provided the application does not use inline event handlers. The strictest useful policy for a PHP application without inline scripts is script-src 'self'. When inline scripts are necessary, common in legacy applications or those that embed JSON data in the page, a nonce-based approach allows specific inline blocks while blocking all others.

Generating a Nonce in PHP

A nonce is a random, base64-encoded string that PHP generates fresh for every request and embeds in both the CSP header and the permitted script tags. The browser checks that the nonce in the script tag matches the one in the header, and rejects everything else. Use PHP's random_bytes() to generate the raw bytes, and base64_encode() to turn them into a string suitable for the attribute. The same nonce value must appear in the script-src 'nonce-...' directive and in the nonce attribute of every legitimate inline script tag on the page. A nonce reused across requests is worthless. The defense relies on the value being unpredictable to an attacker who injects markup.

A working nonce pattern in PHP: generate the nonce at the top of the request, store it in a variable, emit the CSP header with header("Content-Security-Policy: script-src 'nonce-$nonce'"), and output script tags with <script nonce="$nonce">. The CSP header must be sent before any HTML or whitespace. A common failure is sending the header after a PHP notice or a stray newline has already flushed the output buffer. The header is silently dropped.

CSP as a Monitoring Tool

Deploy a Content-Security-Policy in report-only mode before enforcement. Use the Content-Security-Policy-Report-Only header and a report-uri directive that points to a collector endpoint. The browser sends JSON violation reports but does not block anything. Run report-only mode for a week on production traffic. It reveals every inline script, eval() call, and third-party resource that the real policy would break. Fix or whitelist them before turning on enforcement. Skipping the report-only phase on a large PHP application is the single largest cause of CSP rollbacks.

The X-XSS-Protection header is a predecessor to CSP that some guides still recommend. Modern browsers have deprecated it. A CSP with a strict script-src directive makes it redundant. Set X-XSS-Protection to 0 in a CSP-protected application. The old header can introduce cross-site data leaks in some edge cases.

Cross-Site Request Forgery tricks a user's browser into making an unwanted request to a site where the user is already authenticated. The browser automatically attaches session cookies. The server sees a valid, authenticated request. The defense is a CSRF token: a random value the server generates, stores in the PHP session, and embeds in forms and AJAX calls. The server compares the submitted token to the session token on every state-changing request. A mismatch means the request did not originate from the site's own form. Reject it.

Token Generation and Validation

Token generation requires a cryptographically secure random source. PHP's random_bytes(32) returns 32 raw bytes. bin2hex() or base64_encode() converts them to a string suitable for a hidden form field. Store the token in $_SESSION['csrf_token'] after session start. Every POST, PUT, PATCH, and DELETE request reads the token from the request body or a custom header and compares it with a timing-safe string comparison to the session value. hash_equals() is the PHP function for timing-safe comparison. A standard === comparison leaks timing information that can be exploited to guess the token byte by byte.

A common mistake is generating one token per session and reusing it. An attacker who can read a single token, through a log leak, a misconfigured error page, or a reflected XSS on a subdomain, can forge requests for the lifetime of that session. The stronger pattern binds each token to a specific action or regenerates it after each use. For most PHP applications, a single token per session is an acceptable trade-off when combined with the SameSite cookie attribute. High-value actions like password changes or fund transfers should require re-authentication or a fresh token.

AJAX and Single-Page Applications

An AJAX-driven frontend cannot read a CSRF token from a hidden form field because there is no form. Deliver the token as a cookie that JavaScript reads and sends back as a custom header. This works because browsers enforce the same-origin policy for reading cookies but allow a site to read its own cookies via JavaScript. The server sets a non-httponly cookie with the token value. The client-side code reads it and attaches it as an X-CSRF-Token header. The server validates the header value against the session token. Scope the cookie with the Secure and SameSite flags to prevent it from leaking over plain HTTP.

The OWASP Cheat Sheet on XSS prevention is the reference every PHP developer should bookmark. It organises defenses by output context and provides positive security models: define what is allowed rather than trying to block known attack patterns. The cheat sheet divides the problem into HTML body, HTML attribute, JavaScript, CSS, and URL contexts, each with a recommended encoder. For PHP specifically, the cheat sheet recommends htmlspecialchars with ENT_QUOTES for HTML contexts, json_encode with hex flags for JavaScript, and rawurlencode for URL parameters.

The cheat sheet's most important rule for PHP is the first one: never insert untrusted data into a dangerous context unless you have encoded it for that exact context. Dangerous contexts include <script> blocks, HTML comment blocks, attribute names, tag names, and CSS values. PHP templating engines like Twig and Blade provide automatic context-aware escaping. The developer must still tell the engine which context a variable enters. A Blade {{ $var }} escapes for HTML. Using {!! $var !!} bypasses escaping and should only appear in a codebase when the variable is already sanitised HTML. That is nearly never.

Another OWASP recommendation: validate input on arrival and encode on departure. Input validation rejects data that does not match the expected format, a numeric ID, a date, a UUID. This reduces the attack surface before encoding ever runs. A PHP application that validates a query parameter as an integer with filter_var($id, FILTER_VALIDATE_INT) and then still encodes it before output is following the defense-in-depth pattern correctly.

The PHP session cookie carries the session identifier that both XSS and CSRF attacks target. Three cookie flags determine how browsers handle it. Many shared-hosting PHP applications still run without two of them. The httponly flag prevents JavaScript from reading the cookie. That blocks cookie theft through XSS. The secure flag tells the browser to send the cookie only over HTTPS. A site that serves the login page over HTTPS but then drops to HTTP on inner pages leaks the session cookie in plaintext on every subsequent request if the secure flag is absent.

The SameSite cookie attribute is the minimum viable backport for PHP applications that cannot yet enforce HTTPS sitewide or that run on hosting where the secure flag is not configurable through the PHP INI. SameSite=Lax tells the browser to send the cookie on same-site requests and on top-level navigations from other sites, but not on subresource requests like images or iframes, and not on cross-site POST requests. This blocks the most common CSRF attack pattern: a malicious form on an attacker's site that POSTs to the victim's bank or CMS. SameSite=Strict blocks the cookie on all cross-site requests, including when a user clicks a link from an email or a chat message and lands on the site. Strict breaks that flow. Lax preserves it while still blocking forged POSTs.

Setting Cookie Flags in PHP

PHP's session cookie settings are controlled through session.cookie_httponly, session.cookie_secure, and session.cookie_samesite INI directives, or through session_set_cookie_params() called before session_start(). On cPanel hosts where the INI directives are not editable through the MultiPHP editor, the function call is the fallback. The call must set all three parameters: lifetime, path, domain, secure, and httponly in the positional arguments, and the samesite parameter in the options array for PHP 7.3 and later.

A working snippet: session_set_cookie_params(['lifetime' => 0, 'path' => '/', 'domain' => '', 'secure' => true, 'httponly' => true, 'samesite' => 'Lax']); session_start(); The secure flag set to true on a site without a valid TLS certificate will cause the session cookie to be rejected by the browser. The user will be unable to log in. Testing the secure flag on a local development host requires temporarily setting it to false. Forgetting to re-enable it before deployment is a common failure.

A PHP application protected by output encoding, a strict Content-Security-Policy, CSRF tokens, and hardened session cookies is not invulnerable. But it raises the cost of exploitation dramatically. The layers back each other up. When output encoding fails on one template, the CSP blocks the script. When a CSP nonce is accidentally reused, the httponly flag prevents session theft through the XSS that got through. When a CSRF token is missing from an AJAX call, the SameSite cookie rejects the cross-site request before the server ever sees it.

Test each layer in isolation. That is the only way to confirm it works. A quick manual check: open the browser's developer tools, look at the response headers for the Content-Security-Policy and Set-Cookie lines, and verify the flags. Submit a form with the CSRF token field removed and confirm the server returns an error or redirects to an error page, not a success response with the action completed. The single thing that most often goes wrong across all these defenses is a deployment that changes the session cookie domain or path, breaking CSRF token lookups because the session and the token now live on different scopes. Test a full login-to-action flow on the production domain after every deployment. That catches the failure before an attacker does.