Skip to content

Security

Common Cross Site Scripting mistakes that still ship

Teams still ship after glancing at a homepage, trusting a WAF badge, or treating CSP as XSS proof—then public reflected or stored template hits show up on the live host.

· by Sam Ortega

Common Cross Site Scripting mistakes that still ship

I keep a short list of XSS mistakes that survive launch week. None of them are exotic. They come from treating the marketing homepage like the whole public attack surface and treating a green uptime tile like a security review. Process that survives handoff has to be boring on purpose.

SlaySlop's Cross-site scripting check "Checks public pages for reflected and stored XSS using known vulnerability templates." The mistakes below fight that observation point.

Outcome if you catch these early

You get tickets that name pages and template classes instead of "fix XSS somehow." Agencies that keep this boring tend to keep clients. The call stays about evidence, not folklore.

Boundaries

Read-only public scan. Permission required. Not a pentest. XSS sits under Security next to CSP and Known CVEs. Closing an XSS finding does not invent a CSP. SlaySlop does not edit the target. Only scan hosts you are authorized to assess.

Loading diagram.

Mistake 1: homepage-only confidence

Attackers and scanners look past the hero image. Search, filters, and contact forms echo input. If your handoff script only opens /, you shipped a glance, not a review.

Mistake 2: treating CSP as XSS proof

CSP "Checks whether browser content sources are restricted by a CSP header." That is a different row. A strong CSP can reduce impact of some script injection classes. It does not erase a reflected or stored finding on a public page. Keep two tickets when you have two gaps.

Mistake 3: WAF badge as a substitute for evidence

Vendor pages that say "XSS protection" are marketing. Your client still needs the public page evidence from a permissioned scan. I have watched a WAF story collapse in five minutes when someone opened the cited search URL.

Mistake 4: staging-only fixes

You harden the preview. Production still runs the old search plugin. The glance was on staging. The finding is on the live host. Pin the environment in every ticket.

bash
# Permissioned: confirm which host you are about to discuss
curl -sI "https://www.example.com/search" | sed -n '1,15p'
curl -sI "https://staging.example.com/search" | sed -n '1,15p'

Mistake 5: collapsing every Security weirdness into one Slack thread

XSS, CSP, client-bundle secrets, and console errors are different sensors. Mixing them into "security weirdness" wastes a week. Product language ranks by exposure and attaches evidence to findings. Borrow that packaging for your tickets.

Mistake 6: promising a pentest you did not run

The published definition is template-based on public pages. It is not authorization to fuzz a stranger's forms. It is not coverage of authenticated account settings the scan never opened. Say the scope out loud on the handoff call.

Mistake 7: fixing the symptom in the wrong layer

Someone disables a security header to quiet a demo. Someone blocks a path in the WAF and leaves the sink in the app. Temporary mitigations without an owner and a removal date become permanent embarrassment. Prefer fixing output encoding or the stored sink on the real page family.

Happy path that avoids the list

  1. Enumerate public hosts and input routes in the SOW.
  2. Run a permissioned SlaySlop scan.
  3. Open XSS evidence on the cited pages.
  4. Check CSP and Known CVEs on the same pass.
  5. Name owners and rescan dates before portal access goes out.
text
XSS mistake watchlist
homepage_only: yes|no
csp_confused_with_xss: yes|no
waf_badge_cited: yes|no
env_pinned: prod|staging|unknown
owner:

Mistake 8: fixing in the ticket title only

Renaming a Jira ticket from "XSS" to "Security hardening" does not change the public page. Neither does marking the ticket done because a WAF rule was "enabled" without a reproduce step. Require a before/after note with the cited URL. Agencies that skip the note relearn the same incident after staff rotation.

Documentation culture is part of the bug

Sometimes the CMS is fine and the runbook is wrong. The runbook says "disable escaping for the marketing search widget." A tired engineer applies the runbook to production. The mistake shipped as documentation culture. Fix the runbook in the same change window when you fix the sink. Otherwise the next on-call will reintroduce the reflection while "following the docs."

Process that survives launch week looks like a checklist you can hand to someone who was not on the build. Not like a hero engineer who remembers which plugin was sketchy.

Client calls that go sideways

The awkward call usually starts with "but we have Cloudflare" or "but we ran a plugin scan last year." Neither statement answers whether public pages currently show reflected or stored template hits. Bring the SlaySlop evidence to the call. Open the cited URL. Let the page argue for you.

Related next step

When a finding fires, reproduce on the permissioned public URL before changing global WAF rules. Soft read: Cross-site scripting and the checks catalog.