Check framing protection on account actions
Inventory pages that change account state and verify their frame policy. Test approved embedding separately from blocked framing on sensitive screens.
Account actions should not become clickable controls inside an unrelated page unless the product explicitly supports that arrangement. Review the rendered document that contains the control, not only the API it calls. An authorized API request can still follow a misleading browser interaction.
OWASP's clickjacking guidance describes CSP frame-ancestors and X-Frame-Options. Apply framing policy through HTTP response headers. Do not treat a visible banner or a client-side frame check as equivalent protection.
Classify pages by embedding need
List the routes for password changes, organization membership, connected applications, and billing decisions. Distinguish these from a deliberately embeddable read-only widget. A site-wide exception added for one widget can expose unrelated account screens.
| Page class | Intended parent | Verification case |
|---|---|---|
| Account settings | No external parent | Controlled external frame is refused |
| Administrative approval | No frame | Action page cannot load in a parent document |
| Approved widget | Named integration origins | Approved parent works; unrelated parent fails |
| Authentication error | Same policy as its route | Failure response does not lose protection |
Record the final response headers after the CDN and reverse proxy. A correct application setting is not enough if another layer removes or replaces it.
Use harmless browser fixtures
Build a local or approved test parent that attempts to frame the selected page. Use synthetic accounts and a non-destructive target action. Observe the browser's refusal and developer-console explanation; do not rely only on the page looking blank.
For an allowed integration, test the legitimate parent and an unapproved parent independently. Include nested framing if the integration uses it. Check the whole authentication journey because a redirect may end at a document with a different policy.
Review exceptions at the document boundary
Keep the policy with the route that renders the document. An API-only response does not stand in for a missing header on the page. Similarly, the presence of SameSite cookies does not establish which origins may frame a document.
Save route, parent origin, browser version, observed header, and outcome in the review record. Assign a renewal date to integration exceptions. Retest when the site adds an embedded surface or changes edge configuration. The success criterion is specific: required embedding continues to work, while account-changing documents cannot be presented by unapproved parents.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.