TL:DR; A web server which enforces HSTS will instruct web clients to force HTTPS on all outgoing requests, even if they are towards another domain.
max-age
header (which must be at least 6 months) which the browser will use to remember for how long HSTS should be used.TL:DR; A web client connecting to a web server, which instructs the client to use X-Frame-Options, will not allow the client to render the web page in an HTTP frame to protect the user from clickjacking attacks when browsing domains.
<iframe>
has historically been used with malicious intent through Clickjacking attacks and in order to protect against them X-Frame-Options should be used. The purpose of X-Frame-Options is to prevent this with respect to HTTP frames. The reason this is relevant is that it its otherwise possible to not just render the content of a domain but also change it's appearance.<button>
in the invisible frame which performs, for example, a bank transaction could be aligned on top of another button which the user is compelled to press in the malicious web page.X-Frame-Options
HTTP header which either (1) denies any framing or (2) allows framing but only for the same domain which the web server made the reply for.TL:DR; A web browser is logged into a website, another website which the user visits may be able impersonate the user and thus perform actions as the user unless a CSRF protection mechanism is implemented.
TL:DR; A web server instructs a web browser to store information in a cookie will not protect from information leakage unless the default configuration is overridden.
secure
directive does! It allows the web browser to be instructed to prevent sending the cookie.HttpOnly
directive instructs the web browser to only allow cookies to be accessed for outgoing HTTP requests. Why is this important you might ask? Most often the JavaScript which a web page executes is not written entirely by ourselves but by a third party. Since we also often store sensitive credentials in the cookie any script will be able to access the cookies using document.cookie
and steal it unless the HttpOnly
directive is set.domain
directive is not set, only the same domain which instructed the web browser to set the cookie can access it. This is most often the preferred usage.domain=domain.tld
directive you actually allow all subdomains to domain.tld to access the cookie. If you are not entirely in control of the DNS this usage should be used with caution as malicious.domain.tld would also be able to access the cookie.domain
directive, the web browser permits other domains and its subdomains to access a cookie. If you do not want the subdomains to access the cookie, use the hostOnly=true
directive!SameSite
directive instructs whether the web browser should send cookies in cross-origin requests. The purpose of the directive is to offer (some) protection against CSRF attacks. The directive can be set to three distinctive values: Strict
. Lax
and None
.Note: TheSameSite
directive demands thatSecure=true
is also used. The directive will not have any effect otherwise.
<a href="bar.com">
link which the user clicks, no cookies will be sent to bar.com. As such this is more suited for high security environments such as bank sites but not your average web page. If facebook.com implements SameSite=Strict
it means that if you have previously logged into Facebook you will be prompted to login again if you arrive from a google search since the Facebook cookie with your login credentials is not sent.Strict
but will allow cross-origin HTTP GET
requests. This means that it would be possible to login to Facebook in the example above with SameSite=Lax
when the user clicks on a <a href="facebook.com">
link. Note that Lax
still does not send cookies for AJAX, iframe, or any other request type except pure HTTP GET requests.TL:DR; A web browser which receives a resource with incorrect MIME type will try to identify it in a manner which could be exploited. As a preventive measure, the web browser should be instructed to reject resources with absent or incorrect MIME type.
X-Content-Type-Options
header specifies how the web browser should handle resources such as stylesheets and scripts which have either an incorrect MIME type or no explicitly defined MIME type. nosniff
directive, the browser is instructed to not load any resources which does not have an explicit MIME type, thereby protecting the end-user against attacks which exploit incorrect MIME type identification. Note:X-Content-Type-Options
has only one directive:nosniff
. This means that the header can be regarded as a boolean where the header is either set with thenosniff
directive or is not set at all.
TL:DR; A web client connecting to a trusted web server, which instructs the client to use CSP, will not trust JavaScript originating from other domains unless explicitly specified.
<script src="malicious.domain.com">
.TL:DR; A web server which enforces CORS will not accept any script-initiated requests originating from a web client which is connected to a web server on any other domain unless explicitly specified.
XMLHttpRequest
.Access-Control-Allow-Origin
HTTP header. This will instruct the web client if a content from the domain A (or any domain) is allowed to make request to domain B.integrity
and crossorigin
.