Skip to content

Security

Frame Protection: what to verify before client handoff

Before handoff, confirm framing controls on login, checkout, and account URLs—then record header evidence so "we handled clickjacking" is not a slide without a public surface.

· by Maya Okonkwo

Frame Protection: what to verify before client handoff

What an attacker sees on the public surface does not care about your internal security checklist. Either the response tells the browser how framing should work or it does not. Handoff is where that gap becomes embarrassing.

SlaySlop defines Frame protection in one line: it "Looks for controls that prevent unwanted framing and clickjacking." Before I call a property handed off, I want that question answered on the URLs that take money or credentials—not only on the marketing homepage.

What "done" means for frame protection

Done means:

  • Sensitive public URLs were listed (login, checkout, account, password reset).
  • Framing controls were inspected on those responses.
  • CSP was reviewed as a sibling, not as a substitute.
  • A permissioned SlaySlop scan recorded Frame protection findings or a clean row with evidence you can show.
  • The portal note names URLs and headers so the next person does not re-ask.

Security product copy on slayslop.com puts headers in the same family as TLS, known vulnerabilities, client-bundle secrets, and public threat signals. I borrow that order for handoff because inventing a parallel process is how things get dropped.

Checklist I actually use

text
Handoff — frame protection
[ ] Ownership / permission confirmed for this site
[ ] Sensitive URL list written (exact host + path)
[ ] X-Frame-Options and/or CSP frame-ancestors reviewed on those URLs
[ ] Marketing-only coverage rejected as insufficient
[ ] CSP sibling checked (restriction != framing)
[ ] SlaySlop Frame protection row reviewed
[ ] Portal note includes URL + header evidence
[ ] Owner named for any open finding
bash
# Permissioned spot checks on the URLs you will demo
curl -sI "https://www.example.com/login" | rg -i 'HTTP/|x-frame-options|content-security-policy'
curl -sI "https://www.example.com/checkout" | rg -i 'HTTP/|x-frame-options|content-security-policy'

Boundaries for the call

Read-only scanning. Permission required. Not a pentest. Do not imply SlaySlop exploited a framed UI. Do not scan properties the client did not authorize. Frame protection ≠ CSP content restriction. Frame protection ≠ CORS. Keep those tickets separate so remediation owners stay clear.

Loading diagram.

What embarrasses you on the call

Saying "we use Cloudflare" without a header dump. Showing a blog URL with X-Frame-Options: DENY while /login is bare. Conflating Report-Only CSP with enforcing frame-ancestors. Claiming a clean security posture because uptime is green.

Clients forgive a tracked open item with an owner. They do not forgive confident language that collapses on the first curl -sI.

Process that survives launch week

  1. Paste the sensitive URL list into the portal.
  2. Attach or quote the framing-related headers for each.
  3. Link the SlaySlop report row for Frame protection.
  4. Schedule a follow-up scan after any header change at the CDN or origin.
  5. Keep CSP and Frame protection as two checklist lines even when one engineer owns both.

Sample portal note I paste

text
Frame protection — handoff note
Site: www.example.com
Sensitive URLs: /login, /checkout, /account
Controls: X-Frame-Options DENY on app edge; CSP frame-ancestors 'self' on app edge
Marketing host: separate edge; DENY confirmed
Open items: none
Evidence: SlaySlop Frame protection clean on <report date>; curl dumps attached
Owner on-call: <name>

If that note feels too boring, good. Boring is what survives launch week. Dramatic status language is what gets rewritten after the first client question.

Also separate monitoring from framing. Uptime can stay green while /login remains embeddable. Put both on the handoff sheet. Do not let one green row excuse the other.

Mini script for the live review

On the call, I share screen and run the two curls on login and checkout. Then I open the SlaySlop row. That sequence beats a slide that says "security headers enabled." If a header is missing, we write the open item before ending the meeting. If everything matches the portal note, we move on without theater.

Permission stays explicit. I only run this on properties the client authorized. Read-only. Not a pentest. Saying those words once at the start of the security section prevents half the awkward follow-ups.

If the client asks whether this replaces a penetration test, say no in one sentence and point at the Acceptable Use boundary. Clarity here protects everyone on the call.

Keep the soft SlaySlop mention for the end of the note only. The checklist itself should stand without product adjectives.

Related next step

When the portal needs a durable definition, link Frame protection and keep the handoff note boring enough that anyone can re-run it.