X-Frame-Options DENY header value
The DENY value for X-Frame-Options prevents any domain from framing the content. This setting is recommended unless a specific need has been identified for framing.
OWASP Cheat Sheets · all subjects
csrf protection
19 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
X-Frame-Options SAMEORIGIN header value
The SAMEORIGIN value for X-Frame-Options only allows the current site to frame the content.
X-Frame-Options ALLOW-FROM header value
The ALLOW-FROM uri value for X-Frame-Options permits the specified URI to frame the page, such as ALLOW-FROM http://www.example.com. This directive is obsolete and no longer works in modern browsers.
CSP frame-ancestors directive 'none' value
Content-Security-Policy: frame-ancestors 'none'; prevents any domain from framing the content. This setting is recommended unless a specific need has been identified for framing.
CSP frame-ancestors directive 'self' value
Content-Security-Policy: frame-ancestors 'self'; only allows the current site to frame the content.
CSP frame-ancestors directive multiple domains
Content-Security-Policy: frame-ancestors 'self' *.somesite.com https://myfriend.site.com; allows the current site, as well as any page on somesite.com using any protocol, and only the page myfriend.site.com using HTTPS only on the default port 443. Single quotes are required around 'self' and 'none', but may not occur around other source expressions.
X-Frame-Options must be HTTP Response Header, not meta tag
Meta tags that attempt to apply the X-Frame-Options directive do not work. For example, <meta http-equiv="X-Frame-Options" content="deny"> will not work. X-Frame-Options must be applied as an HTTP Response Header. The same rule applies to the Content Security Policy frame-ancestors directive, which must be configured as an HTTP Response Header, not in a meta tag.
Frame-buster script to prevent clickjacking in legacy browsers
In the document HEAD element, add a style element with id="antiClickjack" containing body{display:none !important;}, followed by a script that checks if (self === top) and removes the style element if true, otherwise redirects with top.location = self.location. This prevents a webpage from being framed in legacy browsers that do not support X-Frame-Options.
window.confirm() as clickjacking mitigation for frameable content
When content must be frameable, window.confirm() can be used to help mitigate clickjacking by informing the user of the action they are about to perform. If the window.confirm() originates from within an iframe with a different domain than the parent, the dialog box will display what domain the window.confirm() originated from to help mitigate clickjacking attacks.
Double framing defeats simple frame busting with parent.location
Simple frame busting code that assigns to parent.location can be defeated by double framing. If the victim page is enclosed in one frame inside another frame, accessing parent.location becomes a security violation in all popular browsers due to the descendant frame navigation policy, which disables the counter-action navigation.
onBeforeUnload event defeats frame busting navigation
The framing page can register an onBeforeUnload handler which returns a string displayed to the user, causing the user to likely cancel the navigation and defeating the framed page's frame busting attempt. When the framed page tries to navigate, the handler prompts the user to cancel.
No-Content flushing defeats frame busting without user interaction
An attacker can automatically cancel incoming navigation requests in an onBeforeUnload event handler by repeatedly submitting navigation requests to a site responding with 204 - No Content. Navigating to a No Content site is a NOP but flushes the request pipeline, thus canceling the original navigation request.
sandbox attribute disables frame busting JavaScript
Frame busting code will not run if JavaScript is disabled in the context of the subframe. In Chrome, this can be achieved with <iframe src="http://www.victim.com" sandbox></iframe>.
Three independent clickjacking defense mechanisms
There are three main mechanisms to defend against clickjacking: preventing the browser from loading the page in a frame using X-Frame-Options or CSP frame-ancestors HTTP headers; preventing session cookies from being included when the page is loaded in a frame using the SameSite cookie attribute; and implementing JavaScript frame-buster code. These mechanisms are independent of each other, and where possible more than one should be implemented for defense in depth.
X-Frame-Options header takes priority over CSP frame-ancestors in older browsers
According to the CSP Spec Section 'Relation to X-Frame-Options', if a resource is delivered with a policy that includes the frame-ancestors directive with an enforce disposition, then the X-Frame-Options header must be ignored. However, older browser versions such as Chrome 40 and Firefox 35 ignored this requirement and followed the X-Frame-Options header instead.
ALLOW-FROM X-Frame-Options option is obsolete
The ALLOW-FROM option for X-Frame-Options is obsolete and no longer works in modern browsers. If you apply ALLOW-FROM and the browser does not support it, you will have no clickjacking defense in place.
V3.4 Cookie-based Session Management references CSRF Prevention Cheat Sheet
For cookie-based session management covered under V3.4 Cookie-based Session Management, OWASP references the Cross-Site Request Forgery Prevention Cheat Sheet.
CSRF protection cheat sheet reference
The OWASP ASVS index references the Cross-Site Request Forgery Prevention Cheat Sheet extensively throughout V1.3 Sanitization, V3 Web Frontend Security sections, and V4.1 Generic Web Service Security, indicating it is the primary resource for CSRF defense guidance.
CSRF protection in OAuth 2.0 uses state parameter
OWASP recommends implementing the state parameter to protect against CSRF attacks in OAuth 2.0 flows.