Hardening Reference
Cross site scripting — XSS runs in your visitor's browser, wearing your domain
You added a padlock, a firewall and a WAF, and none of the three has anything to say about this.
The short answer
Cross-site scripting is an output bug: a page renders attacker-supplied text as markup instead of as text, and the resulting script runs in your visitor's browser with your domain's privileges.
That last clause is the whole problem. The script can read anything the page can read, including session cookies that are not flagged against it, and everything it does is attributed to you. HTTPS protects the journey and changes none of this, because the script is already inside the page when it arrives.
By the HostingFast team · Reviewed 24 August 2026
0
Hand-waving in this entry
100+
Entries wired to each other
Real
Numbers you can reproduce
Free
To read, no gate
It comes in three shapes. Stored XSS lives in your database — a comment, a profile field, a product review — and fires for every visitor who loads the page. Reflected XSS rides in a URL parameter that the page echoes back, and needs the victim to follow a crafted link. DOM-based XSS never touches the server at all; the page's own JavaScript writes untrusted input into the document.
The fix in code is escaping at the point of output, matched to the context — HTML body, attribute, URL, JavaScript — because each context escapes differently. In WordPress that is the escaping helpers on every echo. What you can do without touching code is cap the damage, and that is a header and two cookie flags.
Escape on output, not on input
Sanitising on the way in feels tidier and is the wrong place. You do not know at input time whether the value will end up in a page body, inside an attribute, in a URL or inside a script block, and each of those needs different treatment. Escape when you render, against the context you are rendering into, and the same stored value stays correct everywhere.
The cost is nothing measurable. Escaping a few hundred strings per page is far below the noise floor of a database query, so nobody has ever traded XSS safety for a faster page and been right about it.
Headers you can set today from .htaccess
A Content-Security-Policy header tells the browser which sources of script it is allowed to execute, which turns an injected inline script into a console error. Add X-Content-Type-Options to stop content sniffing and Referrer-Policy to stop leaking paths. All three are header lines in .htaccess, and LiteSpeed reads your Apache configuration as written, so nothing needs porting.
Roll it out with the report-only variant first. A real policy on a WordPress site with page builders and analytics will break something on the first attempt, and report-only mode tells you exactly what without any visitor noticing.
Cookie flags cap what a successful attempt gets
HttpOnly puts the session cookie out of reach of JavaScript entirely, which removes the single most valuable prize an injected script is after. Secure keeps it off unencrypted connections. SameSite constrains the cross-site request forgery half of the same family. None of the three prevents the injection; all three shrink what it is worth.
Check yours in the browser's application panel rather than assuming. A plugin that sets its own cookies frequently sets them without flags, and the session cookie you were relying on may not be the only one carrying something useful.
Where the platform meets your code
The server-level rule set catches the recognisable injection shapes on the way in, which covers you while a vulnerable component waits for its patch. Staging exists so you can enforce a new policy header, click through the whole site and roll it back without an audience — ten staging copies per account on the WordPress tiers, cloned and restored in one click.
Neighbouring entries: SQL Injection, WAF, HTTPS and Plugin. Free SSL on every plan renews itself ahead of expiry, so the Secure flag has something to work with from day one.
Entries that name the layer responsible
Half the confusion in web security comes from expecting one layer to solve another layer's problem. Every entry here starts by naming which layer owns the failure, because that alone answers most of the question.
Ten staging copies per account on the WordPress tiers, cloned and rolled back in a click, so a header change is never an experiment on live traffic.
- Layer ownership stated first
- Header and flag syntax, not theory
- Rollback plan for every change
- Written by the engineers on support
Why HostingFast
Standard on every plan
The bug, correctly located
An output-escaping failure in your page, not a transport failure on the wire.
Three shapes told apart
Stored, reflected and DOM-based need different tests, and the third never touches your server.
Context-aware escaping
Body, attribute, URL and script escape differently, which is why input sanitising is the wrong place.
Headers you can ship today
CSP, X-Content-Type-Options and Referrer-Policy are .htaccess lines, and LiteSpeed reads them as written.
Damage capped by flags
HttpOnly, Secure and SameSite do not prevent injection — they make it worth much less.
Rolled out without an audience
Report-only mode first, on a staging copy, then enforce. That is the whole safe path.
Quick Start
From order to online
- 1
Audit your cookie flags
Open the browser's application panel and read the flags on every cookie the site sets. HttpOnly missing on a session cookie is the finding, and it is common.
- 2
Ship CSP in report-only mode
Add the report-only header on staging and click through the whole site. It will name every inline script and third-party source you forgot about.
- 3
Enforce, then re-test the checkout
Switch to the enforcing header and walk the paths that involve money. Payment scripts are the ones a strict policy breaks quietly.
Built In
Loaded onto every plan
- Daily backups, with self-service restores you run from the panel
- Spam and virus screening on every mailbox as standard
- NVMe SSD storage on every tier, not just the expensive ones
- Built-in WebP image optimisation at no extra cost
- cPanel — the control panel most of the industry already runs
- 99.9% uptime as the target, monitored around the clock
- Your existing site moved over by our engineers, free of charge
- WordPress and 400+ other applications installed in one click
- Browser webmail plus IMAP, POP and SMTP for any mail app
- Money-back cover: 30 days on hosting plans, 7 on reseller
Frequently Asked
What people ask us most often
Can I set a Content-Security-Policy on shared hosting?
Yes. It is a header line in .htaccess, and LiteSpeed reads Apache configuration as written, so nothing needs converting. Start with the report-only variant, collect what it flags for a week, then switch to the enforcing header. Doing it in the other order breaks a page builder and you find out from a customer.
My policy broke the theme. What usually causes that?
Inline scripts and inline styles, nearly every time — page builders, analytics snippets and payment widgets all inject them. The honest options are to allow the specific sources you need, or to move those scripts into files you control. Adding a blanket allowance for inline script technically satisfies the header and removes most of its value.
Does escaping every output slow the page down?
No. Escaping a few hundred strings is orders of magnitude below the cost of a single database query, so it never appears in a profile. If a page is slow, look at queries, external HTTP calls and uncached fragments. Escaping has never been the answer to that question.
Where can I test header changes without risking the live site?
On a staging copy. The WordPress tiers here give you ten per account, cloned in a click and rolled back the same way, so you can enforce a policy, break something, and undo it without a visitor ever seeing it. Push to live once the whole click-through is clean.
Keep reading
HTTPS
The encrypted transport underneath — and why it has nothing to say about this entry.
WAF (Web Application Firewall)
Request inspection above the packet filter, and what it catches while you wait to patch.
How to Test Your Website Speed
Splitting a response time into its four parts and fixing the one that is costing you.
Domain Names
Find, register and transfer names, with the first year free alongside annual hosting.
Web Hosting
cPanel hosting on NVMe with SSL, migration and a first-year domain included.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Test the header change on a clone first.
Ten staging copies per account on the WordPress tiers, LiteSpeed underneath, and free SSL on every plan.
View Domain Names plans