![\"Expertise](\"https:\/\/int64software.com\/blog\/wp-content\/uploads\/2018\/11\/emx-800-high.png\")
<\/a><\/figure>\n\n\n\nContents<\/h2>\n\n\n\n
The series will be consist of the following topics:<\/p>\n\n\n\n
- HTTP Security Headers
- 1a. HSTS Preloading<\/a><\/li><\/ul><\/li>
- User Session Security<\/a><\/li>
- Database Security<\/a> <\/li>
- Safely Handling User Input<\/a> <\/li><\/ol>\n\n\n\n
Topics Not Covered<\/h3>\n\n\n\n
I have opted not to cover server infrastructure security concerns at this time due to the huge number of possible configurations (hosting packages or VPS, operating systems, dashboard systems, firewalls, etc.) While I may cover some of these specifically in future articles, there\u2019s too much nuance in these subjects to be able to do them justice here.<\/p>\n\n\n\n
Disclaimer<\/h3>\n\n\n\n
Everything presented in this article is the result of years of experience, or trial and (frequent) error. Messing around with HTTP headers on a live site can (and likely will) lead to unexpected, possibly disastrous results. The information presented here is correct to the best of the author’s knowledge, but in matters of security we strictly advise the reader to make sure they carry out additional research and understand the dangers before making any changes to their own systems or web sites. Any code presented here is done so as example only, and may be incomplete or contain errors. Readers should be careful when copying and pasting code from any website, this site included. Int64 Software Ltd, its employees and its representatives accept no liability for damage caused by the misuse, either intentional or unintentional, of the information presented in its posts and articles.<\/p>\n\n\n\n
Section Overview<\/h2>\n\n\n\n
When it receives a standard HTTP GET request, a web server\nwill return the information that was requested along with certain header\ninformation. This is necessary information so that your browser knows how to\nhandle the response data, things like the encoding method, and length of the\ndata.<\/p>\n\n\n\n
In this part of the series, we\u2019ll be looking at the security related headers, what they do, and how to set them.<\/p>\n\n\n\n
Configuring Web Servers<\/h2>\n\n\n\n
![\"Configuring](\"https:\/\/int64software.com\/blog\/wp-content\/uploads\/2018\/11\/webservers-2.jpg\")
<\/figure>\n\n\n\nDepending on your web server setup, the way you set headers will vary. Below are some of the more popular options and information on how to set headers.<\/p>\n\n\n\n
Apache Web Server<\/h3>\n\n\n\n
In Apache you\u2019ll need to use the \u201cHeader\u201d directive in either your .htaccess, .httpd.conf or the VirtualHost section of your virtual host configuration file.<\/p>\n\n\n\n
Header set [HeaderName] [HeaderValue]<\/code><\/pre>\n\n\n\nNginx<\/h3>\n\n\n\n
In your Nginx \u201cconfig<\/em>\u201d folder, open the \u201cnginx.conf<\/em>\u201d file and add the following:<\/p>\n\n\n\n
add_header [HeaderName] \"[HeaderValue]\";<\/code><\/pre>\n\n\n\nIIS<\/h3>\n\n\n\n
Add a customHeaders section to the \u201c<system.webServer><\/em>\u201d section in your \u201cWeb.Config<\/em>\u201d file:<\/p>\n\n\n\n
<httpProtocol>\n\t<customHeaders>\n\t\t<add name=\u201d[HeaderName]\u201d value=\u201d[HeaderValue]\u201d \/>\n\t<\/customHeaders>\n<\/httpProtocol><\/code><\/pre>\n\n\n\nPHP<\/h3>\n\n\n\n
In PHP, headers can be defined at the very top of your PHP file (before any actual output has been sent, including blank spaces<\/strong>) using the \u201cheader<\/em>\u201d function.<\/p>\n\n\n\n
header('[HeaderName]: [HeaderValue]', true);<\/code><\/pre>\n\n\n\nNote that headers only need to be set once per request, not in every included PHP file. The \u201ctrue<\/em>\u201d part of this command indicates that an existing header with this name should be replaced if encountered.<\/p>\n\n\n\n
ASP.NET<\/h3>\n\n\n\n
In your \u201cglobal.asax<\/em>\u201d file add the following code:<\/p>\n\n\n\n
protected void Application_BeginRequest(object sender, EventArgs e)\n{\n\tHttpContext.Current.Response.AddHeader(\u201c[HeaderName]\u201d, \u201c[HeaderValue]\u201d);\n}<\/code><\/pre>\n\n\n\nThe Headers<\/h2>\n\n\n\n
![\"HTTP](\"https:\/\/int64software.com\/blog\/wp-content\/uploads\/2018\/11\/headers.jpg\")
<\/figure>\n\n\n\nX-Frame-Options<\/h3>\n\n\n\n
The \u201cX-Frame-Options\u201d header is used to prevent\n\u201cClickjacking\u201d, which is where an attacker attempts to make window user events\nsuch as clicking on a button do something other than the intended action. This\nmay be done by, for example, embedding your webpage in an iframe on their own\nsite and overlay a transparent interface over the top so that, while the user\nthinks they\u2019re using your website, they\u2019re actually feeding information to the\nattacker.<\/p>\n\n\n\n
By setting X-Frame-Options you can tell the client browser\nthat this page should not be allowed to load in a frame or iframe.<\/p>\n\n\n\n
X-Frame-Options has three valid values:<\/p>\n\n\n\n
DENY<\/strong><\/p>\n\n\n\n
This outright prevents any domain from rendering the page in a frame. This is the recommended setting for all pages except where a need has been specifically identified.<\/p>\n\n\n\n
SAMEORIGIN<\/strong><\/p>\n\n\n\n
This will allow you to load your own content in frames, but will not allow it on other domains (including sub-domains).<\/p>\n\n\n\n
ALLOW-FROM <uri><\/strong>
<\/p>\n\n\n\nThis prevents the page from being loaded in frames except for the specified URI (e.g. \u201cALLOW-FROM https:\/\/myothersite.com\u201d). Note that browser support for this value is limited.<\/strong><\/p>\n\n\n\n
Recommended Value<\/h4>\n\n\n\n
X-Frame-Options should always be set to \u201cDENY<\/em>\u201d unless a need has been identified for it to be set otherwise.<\/p>\n\n\n\n
Other Notes<\/h4>\n\n\n\n
X-Frame-Options is still widely supported, but has been deprecated in favour of the \u201cframe-src\u201d Content Security Policy (CSP) directive which is covered later. It is worth still including however as CSPs are only supported in Internet Explorer from version 11, X-Frame-Options support goes back to version 8.<\/p>\n\n\n\n
\n\n\n\nX-XSS-Protection<\/h3>\n\n\n\n
Designed to prevent Cross-site\nscripting (XSS), the \u201cX-XSS-Protection\u201d header allows you to enable XSS\nfiltering in the client\u2019s browser. XSS is an attack whereby the attacker\ninjects scripts into your website through, for example, the use of improperly\nsecured user input fields, and those scripts then either steal data or\notherwise impact on the use of the page where that script is loaded.<\/p>\n\n\n\n
A common example of this can be\nseen in certain recent hacking incidents where scripts were injected through\ncompromised ad networks. The end result could be that instead of submitting\npayment details to the site you\u2019re on, they get sent to a hacker instead.<\/p>\n\n\n\n
The X-XSS-Protection header reduces this risk by instructing browsers to filter and block XSS attacks. It has 4 possible values:<\/p>\n\n\n\n
0.<\/strong>
DisablesXSS filtering (not recommended)
1.<\/strong>
EnablesXSS filtering. If detected, the browser removes the unsafe code and displaysthe page as normal. This is usually the default.
1; mode=block<\/strong>
EnablesXSS filtering. If detected, the browser blocks the page from rendering.
1; report=<reporting-uri><\/strong>
EnablesXSS filtering and sanitizes the page if detected. It will then report theviolation to the specified URI.<\/p>\n\n\n\nRecommended Value<\/h4>\n\n\n\n
X-XSS-Protection should be set to 1, optionally enabling theblock or reporting options as your service requires.<\/p>\n\n\n\n
Other Notes<\/h4>\n\n\n\n
As with the X-Frame-Options, this value should be setalongside a strong Content Security Policy which fully disables the use ofinline scripts. This is covered later.<\/p>\n\n\n\n
\n\n\n\nX-Content-Type-Options<\/h3>\n\n\n\n
This header only has one possible value (\u201cnosniff<\/em>\u201d) and a single purpose: it will\nprevent the client\u2019s browser from interpreting files as anything other than\nthat declared by the content type header.<\/p>\n\n\n\n
When a browser downloads a file, in addition to being told\nwhat the file type is by the Content-Type header, it will perform Content\nSniffing (or Media Type Sniffing or MIME Sniffing) where it uses various\ntechniques to find out what the file is and then handle it appropriately.<\/p>\n\n\n\n
However, this can lead to files which the user expects to be of one type, being another completely, which can result in attacks such as cross-site scripting or malware distribution.<\/p>\n\n\n\n
Recommended Value<\/h4>\n\n\n\n
As mentioned above, X-Content-Type-Options should be set to \u201cnosniff<\/em>\u201d to block this behaviour.<\/p>\n\n\n\n
\n\n\n\nStrict-Transport-Security<\/h3>\n\n\n\n
The HTTP Strict Transport Security (HSTS) header is used to\nnotify a browser that it should only interact with this server over a secure\nHTTPS connection, and never on an unencrypted HTTP protocol.<\/p>\n\n\n\n
The header has two values to set:<\/p>\n\n\n\n
max-age=<MaxAgeInSeconds><\/strong>
Indicates for how long (in seconds) the browser should remember that this site must only be accessed over HTTPS.
includeSubDomains<\/strong>
If specified, indicates that all sub-domains of this site should also only use secure HTTP connections.<\/p>\n\n\n\nRecommended Value<\/h4>\n\n\n\n
This header should be defined with the maximum age set to some appropriate values such as 1 year (31536000 seconds). Optionally, the includeSubDomains property can be set if you require it.<\/p>\n\n\n\n
Strict-Transport-Security: max-age=31536000; includeSubDomains<\/code><\/pre>\n\n\n\n
\n\n\n\nContent-Security-Policy<\/h3>\n\n\n\n
Perhaps the most important, widely supported and often\ndifficult to understand header is the Content Security Policy. This single\npolicy, if configured correctly, can do the most good for securing your\nwebsite. But if misconfigured, can break a lot of things.<\/p>\n\n\n\n
The policy\u2019s settings are mostly concerned with specifically\ndictating where scripts and server resources can be loaded from.<\/p>\n\n\n\n
A CSP header consists of two parts: a directive and a list\nof sources. Directives specify the type of resource you\u2019d like to control, and\nthe list of sources specify where the current directive can be safely loaded\nfrom.<\/p>\n\n\n\n
Note that, as the CSP can contain multiple individual\npolicies, you can either set one header, separating the directives with a\nsemi-colon (;), or you can define multiple Content-Security-Policy headers.<\/p>\n\n\n\n
For example, if I wanted to specify that I would allow JavaScript files from our own server and a JS repository at \u201cjs.example.com\u201d, and style sheets only from our server, I may set a header in either of these two ways (shown in PHP).<\/p>\n\n\n\n
header('Content-Security-Policy: script-src \\\u2018self\\\u2019 js.example.com; style-src \\\u2019self\\\u2019;', true);<\/code><\/pre>\n\n\n\nOr like this:<\/p>\n\n\n\n
header('Content-Security-Policy: script-src \\\u2018self\\\u2019 js.example.com;', false);\nheader('Content-Security-Policy: style-src \\\u2019self\\\u2019;', false);<\/code><\/pre>\n\n\n\nNote that the header replace parameter is changed to \u201cfalse<\/em>\u201d on the latter to allow us to set more than one header with this name.<\/p>\n\n\n\n
Directives<\/h4>\n\n\n\n
default-src<\/strong>
This is what all of the other fetch directives will look to if the fetch type is not explicitly defined. So if an image is requested but the \u201cimg-src\u201d directive isn\u2019t set, then this directive will be used instead.<\/p>\n\n\n\nchild-src (deprecated)<\/strong>
Previously used for web workers and nested browsing contexts such as iframes. However, because of the need to occasionally have separate policies for frames and workers, this is now deprecated in favour of (the un-deprecated) \u201cframe-src<\/em>\u201d and \u201cworker-src<\/em>\u201d.<\/p>\n\n\n\nconnect-src<\/strong>
Restricts sources that can be used by script interfaces (<a> <\/a>pings, Fetch, XMLHttpRequest such as Ajax requests, WebSocket and EventSource)<\/p>\n\n\n\nfont-src<\/strong>
Where fonts can be fetched from (e.g. Google Fonts)<\/p>\n\n\n\nframe-src<\/strong>
When using or <frame> or <iframe> thisspecifies where the source can come from.<\/p>\n\n\n\nframe-ancestors<\/strong>
Unlike frame-src, this directive specifies which sources the current page can be loaded in a frame or iframe. Setting this to \u201cnone\u201d works similar to setting \u201cX-Frame-Options: DENY\u201d.<\/p>\n\n\n\nimg-src<\/strong>
Restrict where images can be loaded from.<\/p>\n\n\n\nmanifest-src<\/strong>
Specifies where application manifest files can be sourced from.<\/p>\n\n\n\nmedia-src<\/strong>
Restricts loading of media using the <audio><\/em> and <video><\/em> HTML5 elements.<\/p>\n\n\n\nobject-src<\/strong>
Restricts the sources of elements using the <object><\/em>, <embed><\/em> and <applet><\/em> tags.<\/p>\n\n\n\nprefetch-src<\/strong>
Where resources may be pre-fetched or pre-rendered from.<\/p>\n\n\n\nscript-src<\/strong>
Valid sources for JavaScript files. This should be tied down to \u2018self\u2019 and any third-party repositories as needed. You should never allow \u2018unsafe-inline\u2019 for scripts as this would allow for inline scripts running and therefore defeats the primary purpose of a CSP, which is to help block XSS attacks.<\/p>\n\n\n\nstyle-src<\/strong>
Restrict where CSS stylesheets can be loaded from.<\/p>\n\n\n\nwebrtc-src<\/strong>
Specifies where WebRTC (Web Real-Time Communications) connections can come from.<\/p>\n\n\n\nworker-src<\/strong>
Valid sources for Worker, SharedWorker and ServiceWorker scripts.<\/p>\n\n\n\nOther Notable Directives<\/h4>\n\n\n\n
form-action<\/strong>
This can be used to restrict the URLs that can be used as the target of a form submission.<\/p>\n\n\n\nreport-uri<\/strong>
Allows you to specify a URI where CSP violations are reported to.<\/p>\n\n\n\nblock-all-mixed-content<\/strong>
Stops the loading of any assets over HTTP when the current page has been loaded over HTTPS.<\/p>\n\n\n\nSources that can be added to Directives
<\/h4>\n\n\n\n*<\/strong>
Allows all sources except for data streams (blob:, data:, filesystem:).<\/p>\n\n\n\n\u2018none\u2019<\/strong>
Blocks all attempts to load this resource type.<\/p>\n\n\n\n\u2018self\u2019<\/strong>
Allows loading resources from the same origin (scheme, host and port).<\/p>\n\n\n\nData:<\/strong>
Data scheme sources are allowed (such as Base64 encoded images).<\/p>\n\n\n\ndomain.example.com<\/strong>
The specified domain is allowed.<\/p>\n\n\n\n*.example.com<\/strong>
The specified domain and all subdomains are allowed.<\/p>\n\n\n\nhttps:\/\/domain.example.com<\/strong>
The specified domain is allowed only over HTTPS.<\/p>\n\n\n\nhttps:<\/strong>
Any domain as long as it is over HTTPS.<\/p>\n\n\n\n\u2018unsafe-inline\u2019<\/strong>
Allows for the use of inline sources, such as element styles or script blocks (shouldn\u2019t be used unless absolutely necessary).<\/p>\n\n\n\n\u2018unsafe-eval\u2019<\/strong>
Allows the use of code evaluation commands such as the JavaScript \u201ceval()\u201d command.<\/p>\n\n\n\n\u2018nonce-<noncevalue>\u2018<\/strong>
Allows a random nonce value to be added to style or script tags which match this \u201c<noncevalue><\/em>\u201d, the styles or scripts in this tag can then be run. Note that bypasses for this have been demonstrated in the past, so it should not be considered secure.<\/p>\n\n\n\n\u2018sha256-<hashvalue>\u2018<\/strong>
Allows scripts or stylesheets to be used if their SHA256 hash matches this value.<\/p>\n\n\n\nRecommended Values<\/h4>\n\n\n\n
This one is a bit harder to recommend an exact value for as it should be catered to your website. My policy (generally when talking about anything security related) is to lock it down as tight as you can, then find out what breaks and then either fix those things, or start loosening it up until you get everything working again. That applies here, but there may be one or two extra steps.<\/p>\n\n\n\n
Let\u2019s consider \u201cstyle-src\u201d, for example. It\u2019s easy enough to lock it down to \u2018self\u2019, meaning that only Cascading Style Sheet (.css) files on the same source can be loaded. But what if you have a few small inline style elements? The best thing to do here is to move them into a css file, but that isn\u2019t always possible or convenient, so you may need to allow \u2018unsafe-inline\u2019.<\/p>\n\n\n\n
I figured the best way to tackle this would be to walk through one of my CSPs, why I made each decision, and what negative connotations it could have.<\/p>\n\n\n\n
default-src 'none\u2019; <\/code><\/pre>\n\n\n\nThe default fall-back is to deny all resources that we haven\u2019t specifically defined below. Since I have gone through and validated all of the other sources, nothing should be reaching this anyway, and if it does then it wasn\u2019t added by me. Be warned that you will get caught out by this when adding new content sources which is why most people set this to “self” instead.
<\/p>\n\n\n\nscript-src 'self' https:\/\/js.stripe.com;<\/code><\/pre>\n\n\n\nI\u2019ve packed and minified all of my own scripts, so only \u2018self\u2019 is required for those (strictly no inline scripts). In addition to that, I use Stripe as a payment platform, so have to allow scripts to be loaded from their JavaScript repository.<\/p>\n\n\n\n
connect-src \u2018self\u2019 https:\/\/api.stripe.com; <\/code><\/pre>\n\n\n\nI make fairly extensive use of Ajax calls, so \u2018self\u2019 is required. Stripe also requires the use of script interfaces, so I allow them as a source. <\/p>\n\n\n\n
img-src 'self' data:; <\/code><\/pre>\n\n\n\nObviously the page in question, having been written after the 1980\u2019s, features images, all of which are self-hosted so \u2018self\u2019 is included. I also make use of some inline SVG graphics, so I include \u2018data:\u2019.<\/p>\n\n\n\n
style-src 'self' 'unsafe-inline' https:\/\/fonts.googleapis.com; <\/code><\/pre>\n\n\n\nStylesheets are mostly self-hosted except for Google Fonts, so both of them are allowed. For my sins I am also guilty of (rarely but occasionally) using some inline styles, so I have allowed \u2018unsafe-inline\u2019 on this directive. Note that proof of concept attacks have been shown for reading form data using CSS injection, so this is a potential weakness you will need to weigh up.<\/p>\n\n\n\n
font-src 'self' https:\/\/fonts.gstatic.com;<\/code><\/pre>\n\n\n\nAnother pretty simple one, we want to allow fonts to be loaded locally and from Google\u2019s Font repository.<\/p>\n\n\n\n
frame-src 'self' https:\/\/*.stripe.com https:\/\/stripe.com; <\/code><\/pre>\n\n\n\nA slightly more complicated one, Stripe allows the authorisation of 3D Secure protected cards. Unfortunately, the advice for implementing this is by using an Iframe (yeah, I hate this too). So here I\u2019ve added Stripe as the payment processor, and \u2018self\u2019 as the authorisation process returns the iframe to a URL of your choice once complete.<\/p>\n\n\n\n
For those that use Stripe, you may note that their documentation states to only add “https:\/\/js.stripe.com” as a frame source, however I’ve found problems with this and am currently working with their support team at the moment to get to the bottom of it.<\/em><\/p>\n\n\n\n
frame-ancestors \u2018none\u2019;<\/code><\/pre>\n\n\n\nAs mentioned previously, this prevents the current page from being loaded in a frame or iframe on this site or any others. Note that I loosen this to \u201cself\u201d on the 3D Secure return page to allow it to be displayed in a frame on my own site.
<\/p>\n\n\n\nreport-uri \/csp-report.php;<\/code><\/pre>\n\n\n\nAny CSP violations should be reported (by the client\u2019s browser) to this URI, where it is logged for later analysis.<\/p>\n\n\n\n
block-all-mixed-content;<\/code><\/pre>\n\n\n\nFinally, even though I don\u2019t have any mixed content, I block it as a matter of course.<\/p>\n\n\n\n
Extra Notes on Other Directives<\/h4>\n\n\n\n
Most of the other directive sources will fallback on the default-src and get blocked. The exception being the worker-src, which will fallback on child-src and then script-src in most browsers (Chrome 59 and higher will skip child-src and go directly to default-src, and Edge 17 will skip script-src).<\/p>\n\n\n\n
By not defining the ‘plugin-types’ directive, this technically defaults to allowing all plugin types (<embed>, <object>, <applet>), however because we don’t define “object-src”, it falls back to default-src and blocks all plugin types at that level.<\/p>\n\n\n\n
Code Examples<\/h2>\n\n\n\n
![\"C++](\"https:\/\/int64software.com\/blog\/wp-content\/uploads\/2018\/11\/code.jpg\")
<\/figure>\n\n\n\nApache Web Server
<\/h3>\n\n\n\nHeader set X-Frame-Options \u201cSAMEORIGIN\u201d\nHeader set X-XSS-Protection \u201c1; mode=block\u201d\nHeader set X-Content-Type-Options \u201cnosniff\u201d\nHeader set Strict-Transport-Security \u201cmax-age=31536000; includeSubDomains\u201d\nHeader set Content-Security-Policy \u201cdefault-src 'none'; script-src 'self' https:\/\/js.stripe.com; connect-src 'self' https:\/\/api.stripe.com; img-src 'self' data:; style-src 'self' 'unsafe-inline' https:\/\/fonts.googleapis.com; font-src 'self' https:\/\/fonts.gstatic.com; frame-src 'self' https:\/\/*.stripe.com https:\/\/stripe.com; frame-ancestors 'none'; report-uri \/csp_report.php; block-all-mixed-content;\u201d<\/code><\/pre>\n\n\n\nNginx<\/h3>\n\n\n\n
add_header X-Frame-Options \u201cSAMEORIGIN\u201d\nadd_header X-XSS-Protection \u201c1; mode=block\u201d\nadd_header X-Content-Type-Options \u201cnosniff\u201d\nadd_header Strict-Transport-Security \u201cmax-age=31536000; includeSubDomains\u201d\nadd_header Content-Security-Policy \u201cdefault-src 'none'; script-src 'self' https:\/\/js.stripe.com; connect-src 'self' https:\/\/api.stripe.com; img-src 'self' data:; style-src 'self' 'unsafe-inline' https:\/\/fonts.googleapis.com; font-src 'self' https:\/\/fonts.gstatic.com; frame-src 'self' https:\/\/*.stripe.com https:\/\/stripe.com; frame-ancestors 'none'; report-uri \/csp_report.php; block-all-mixed-content;\u201d<\/code><\/pre>\n\n\n\nIIS<\/h3>\n\n\n\n
<httpProtocol>\n\t<customHeaders>\n\t <add name=\u201dX-Frame-Options\u201d value=\u201dSAMEORIGIN\u201d \/>\n\t <add name=\u201dX-XSS-Protection\u201d value=\u201d1; mode=block\u201d \/>\n \t <add name=\u201dX-Content-Type-Options\u201d value=\u201dnosniff\u201d \/>\n\t <add name=\u201dStrict-Transport-Security\u201d value=\u201dmax-age=31536000; includeSubDomains\u201d\/>\n\t <add name=\u201dContent-Security-Policy\u201d value=\u201ddefault-src 'none'; script-src 'self' https:\/\/js.stripe.com; connect-src 'self' https:\/\/api.stripe.com; img-src 'self' data:; style-src 'self' 'unsafe-inline' https:\/\/fonts.googleapis.com; font-src 'self' https:\/\/fonts.gstatic.com; frame-src 'self' https:\/\/*.stripe.com https:\/\/stripe.com; frame-ancestors 'none'; report-uri \/csp_report.php; block-all-mixed-content;\u201d \/>\n\t<\/customHeaders>\n<\/httpProtocol><\/code><\/pre>\n\n\n\nPHP<\/h3>\n\n\n\n
header('[HeaderName]: [HeaderValue]', true);\n\nheader('X-Frame-Options: SAMEORIGIN\u2019);\nheader('X-XSS-Protection: 1; mode=block\u2019);\nheader('X-Content-Type-Options: nosniff\u2019);\nheader('Strict-Transport-Security: max-age=31536000; includeSubDomains\u2019);\nheader('Content-Security-Policy: default-src \\'none\\'; script-src \\'self\\' https:\/\/js.stripe.com; connect-src \\'self\\' https:\/\/api.stripe.com; img-src \\'self\\' data:; style-src \\'self\\' \\'unsafe-inline\\' https:\/\/fonts.googleapis.com; font-src \\'self\\' https:\/\/fonts.gstatic.com; frame-src \\'self\\' https:\/\/*.stripe.com https:\/\/stripe.com; frame-ancestors \\'none\\'; report-uri \/csp_report.php; block-all-mixed-content;\u2019);<\/code><\/pre>\n\n\n\nASP.NET<\/h3>\n\n\n\n
protected void Application_BeginRequest(object sender, EventArgs e)\n{\n HttpContext.Current.Response.AddHeader(\u201cX-Frame-Options\u201d, \u201cSAMEORIGIN\u201d);\n HttpContext.Current.Response.AddHeader(\u201cX-XSS-Protection\u201d, \u201c1; mode=block\u201d);\n HttpContext.Current.Response.AddHeader(\u201cX-Content-Type-Options\u201d, \u201cnosniff\u201d);\n HttpContext.Current.Response.AddHeader(\u201cStrict-Transport-Security\u201d, \u201cmax-age=31536000; includeSubDomains\u201d);\n HttpContext.Current.Response.AddHeader(\u201cContent-Security-Policy\u201d, \n \u201cdefault-src 'none'; script-src 'self' https:\/\/js.stripe.com; connect-src 'self' https:\/\/api.stripe.com; img-src 'self' data:; style-src 'self' 'unsafe-inline' https:\/\/fonts.googleapis.com; font-src 'self' https:\/\/fonts.gstatic.com; frame-src 'self' https:\/\/*.stripe.com https:\/\/stripe.com; frame-ancestors 'none'; report-uri \/csp_report.php; block-all-mixed-content;\u201d);\n}<\/code><\/pre>\n\n\n\n![\"OverLAPS](\"https:\/\/int64software.com\/blog\/wp-content\/uploads\/2018\/11\/overlaps-800-tall.png\")
<\/a><\/figure>\n\n\n\nWhat’s Next<\/h2>\n\n\n\n
Please see our addendum to this topic on the use of HSTS Preloading<\/a>, and then continue on to part 2 where we take a look at attacks that can be made against user sessions<\/a>, and how to mitigate them.<\/p>\n\n\n\n
Follow us on Twitter <\/a>for regular updates.<\/p>\n\n\n\n
Reporting Errors<\/h3>\n\n\n\n
- User Session Security<\/a><\/li>
- 1a. HSTS Preloading<\/a><\/li><\/ul><\/li>