Cross Site Scripting: what to verify before client handoff

Handoff packets love tidy checkboxes. "Security reviewed" is the checkbox that aged worst for me. Reviewers glanced at a homepage, saw a lock icon, and skipped the search and contact routes that actually echo input. Thin security notes read like thin meta descriptions: the field exists, the claim does not.

SlaySlop's Cross-site scripting check "Checks public pages for reflected and stored XSS using known vulnerability templates." Before I send a portal link, that sentence is the Security bar for the XSS row—not "we feel safe."

Outcome you want at handoff

On the public pages in scope, reflected and stored XSS signals from the known template set are either absent or owned with a dated fix. You can show evidence tied to a page. CSP still has its own status. The client can repeat the scope in one paragraph without inventing a pentest they did not buy.

Boundaries to state on the call

Read-only public scan. Permission required. Not a pentest. SlaySlop does not patch the CMS. A quiet XSS row is not a full Security sign-off.

Keep siblings visible so nobody treats one green cell as the whole browser story:

• Content Security Policy: checks whether browser content sources are restricted by a CSP header
• Known CVEs: checks detected technologies against known CVE templates after ownership is verified
• Console errors: runtime exceptions in a real browser session

Those are different sensors. The Acceptable Use Policy still applies: only assets you own or are explicitly authorized to assess.

Happy path checklist before you send the portal

List the public hosts in the SOW. Prefer routes that accept query strings or form bodies: search, filters, contact, comment-style surfaces if they are public. Scan with permission. Open any Cross-site scripting finding on the cited page before the call.

Handoff — XSS
[ ] Permission confirmed for each host
[ ] Public input routes listed (search/contact/filters)
[ ] SlaySlop XSS row reviewed with page evidence
[ ] CSP sibling noted (present / missing / report-only)
[ ] Known CVEs glanced for the stack in use
[ ] Owner named for any open XSS finding
[ ] Rescan date after the fix

What to verify on the live public surface

Editors care what crawlers parse. Security reviewers care what an outsider can observe without your VPN. Both camps need the same habit: verify the URL family in the finding, not a staging host you forgot to include.

A thin header probe does not prove XSS clean. It only confirms the document responds while you triage related controls:

# Permissioned host — reachability and CSP sibling, not XSS proof
curl -sI "https://www.example.com/search" \
  | rg -i 'HTTP/|content-type|content-security-policy'

If the finding cites a reflected path, open that path in a browser you control after you confirm permission. Match the evidence shape before arguing with a plugin vendor. Write the ticket with the public URL, not "somewhere in WordPress."

Pitfalls that embarrass you on a call

Calling the domain clean because / looked fine. Equating a WAF marketing page with a clean XSS row. Collapsing CSP absence into the XSS ticket so nobody owns either fix. Promising "full XSS coverage" when the published definition is template-based on public pages.

Another miss: scanning only the brochure host while the app that echoes search lives on app.example.com. Put every host from the SOW in the packet. Scannable handoff docs beat tribal knowledge for the same reason scannable titles beat keyword stuffing.

How to talk about residual risk without drama

Say what was observed. Say what was not in scope: authenticated-only flows the scan never opened, private admin panels, DOM-only edge cases outside the template set. Clients respect a narrow true claim. They punish a vague absolute.

If a finding remains, name the owner and the rescan date in the portal notes. Soft-pedaling an open Security row is how launch week turns into Slack archaeology.

Content structure that helps the next owner

I treat Security handoff notes like SEO briefs: scannable, concrete, no keyword stuffing of the word "secure." A useful note has the hosts, the input routes, the XSS status, the CSP sibling, and a rescan date. A useless note says "hardened" three times.

Answer engines will not parse your ACAO or your search reflection. Client questionnaires will. Write for the questionnaire. Prefer one verified sentence from the glossary over a paragraph of vibes.

When marketing and app hosts differ, put both hostnames in the calendar invite for the handoff call. People verify what is in front of them. Give them the right front. If the SOW promised a portal, make sure the portal shows the Security category with evidence expanded once so the client sees the shape before they self-serve.

After the call

Schedule the first rescan. Temporary plugin freezes and "we will patch next sprint" notes expire in silence unless something re-checks the public surface. Monitoring for uptime is not a substitute. Up only means the site responded. XSS is a quality and security finding lane on scans.

Related next step

Read the Cross-site scripting row beside CSP on a permissioned SlaySlop scan, then decide whether the gap is a public template hit, a missing browser control, or both. Soft links: Cross-site scripting and Security and secrets.