A Content Security Policy, or CSP, is an additional layer of security delivered via an HTTP Header, similar to HSTS technology. This policy helps prevent various kinds of attacks, including Cross-Site Scripting (XSS) and other code injection attacks by defining content sources that are approved, therefore allowing the browser to load them.<\/p>\n
Without a Content Security Policy, the browser will just load all files on the page without considering their source, which could be a harmful site. That puts the site and visitors at higher risk of malicious activity.<\/p>\n
All major browsers offer full or partial support for Content Security Policies.<\/p>\n
However, in the event that someone’s using a really old browser, the Content Security Policy won’t be applied. Content Security Policies are backward compatible which means that older browsers are still able to view webpages that are protected by said Content Security Policies, and vice-versa.<\/p>\n
There are many directives available to website owners who want to implement a Content Security Policy. A server can also define which directives within its own security header. The following list outlines the directives available for use along with their description:<\/p>\n
default-src<\/code>\u00a0Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback),<\/li>\nscript-src<\/code>\u00a0Define which scripts the protected resource can execute,<\/li>\nobject-src<\/code>\u00a0Define from where the protected resource can load plugins,<\/li>\nstyle-src<\/code>\u00a0Define which styles (CSS) the user applies to the protected resource,<\/li>\nimg-src<\/code>\u00a0Define from where the protected resource can load images,<\/li>\nmedia-src<\/code>\u00a0Define from where the protected resource can load video and audio,<\/li>\nframe-src<\/code>\u00a0Define from where the protected resource can embed frames,<\/li>\nframe-ancestors<\/code>\u00a0Specifies valid parents that may embed a page using\u00a0<frame><\/code>,\u00a0<iframe><\/code>,\u00a0<object><\/code>,\u00a0<embed><\/code>, or\u00a0<applet><\/code>.<\/li>\nfont-src<\/code>\u00a0Define from where the protected resource can load fonts,<\/li>\nconnect-src<\/code>\u00a0Define which URIs the protected resource can load using script interfaces,<\/li>\nform-action<\/code>\u00a0Define which URIs can be used as the action of HTML form elements,<\/li>\nsandbox<\/code>\u00a0Specifies an HTML sandbox policy that the user agent applies to the protected resource,<\/li>\nscript-nonce<\/code>\u00a0Define script execution by requiring the presence of the specified nonce on script elements,<\/li>\nplugin-types<\/code>\u00a0Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded,<\/li>\nreflected-xss<\/code>\u00a0Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard\u00a0X-XSS-Protection<\/code>\u00a0header,<\/li>\nreport-uri<\/code> Specifies a URI to which the user agent sends reports about a policy violation<\/li>\n<\/ul>\nThe above directives can all be used when Creating a Content Security Policy, depending on what you want to accomplish.<\/p>\n
How to Create a Content Security Policy<\/h2>\n
Considering the number of directives in the list in the above section, there’s a lot of options available for Administrators to create their Content Security Policy. A CSP format is defined as Content-Security-Policy: policy<\/code>. The following shows a few examples for configuring your\u00a0Content-Security-Policy<\/code>\u00a0header.<\/p>\nExample #1<\/div>\nThis CSP will allow scripts from both the current domain (defined by\u00a0'self'<\/code>) as well as\u00a0https:\/\/www.google-analytics.com<\/code>.<\/p>\nContent-Security-Policy: script-src 'self' https:\/\/www.google-analytics.com<\/code><\/pre>\nExample #2<\/div>\nThe\u00a0default-src<\/code>\u00a0directive set to\u00a0https:<\/code> will allow the browser to load the resource from any origin using\u00a0https:\/\/<\/code>.<\/p>\nContent-Security-Policy: default-src https:<\/code><\/pre>\nExample #3<\/div>\nThis CSP allows for any resource to be loaded from the current domain as well as any subdomain of example.com<\/code>\u00a0(both HTTP and HTTPS).<\/p>\nContent-Security-Policy: default-src 'self' *.example.com<\/code><\/pre>\nExample #4<\/div>\nThe following CSP makes use of the\u00a0frame-ancestors<\/code> the directive which defines which sources are allowed to embed a page using <frame><\/code>,\u00a0<iframe><\/code>,\u00a0<object><\/code>,\u00a0<embed><\/code>, or\u00a0<applet><\/code>. To allow only your site use the following.<\/p>\nContent-Security-Policy: frame-ancestors 'self'<\/code><\/pre>\nExample #5<\/div>\nPorts can also be defined in content security policies. This example restricts resources to be loaded only from\u00a0https:\/\/www.keycdn.com<\/code>\u00a0using port\u00a0443<\/code>.<\/p>\nContent-Security-Policy: default-src https:\/\/www.keycdn.com:443<\/code><\/pre>\nExample #6<\/div>\nThe first part of this example\u00a0default-src 'none';<\/code>\u00a0tells the browser not to load any resources from any sources. While the second part\u00a0script-src https:\/\/www.keycdn.com<\/code>\u00a0tells the browser to allow scripts from\u00a0www.keycdn.com<\/code>\u00a0over\u00a0https:\/\/<\/code>.<\/p>\nContent-Security-Policy: default-src 'none'; script-src https:\/\/www.keycdn.com<\/code><\/pre>\nFor a detailed list of examples and references, visit\u00a0content-security-policy.com<\/a>.<\/p>\n