csp.withgoogle.com
Open in
urlscan Pro
2404:6800:4004:828::2011
Public Scan
Submitted URL: http://csp.withgoogle.com/
Effective URL: https://csp.withgoogle.com/docs/index.html
Submission: On November 21 via manual from NZ — Scanned from NZ
Effective URL: https://csp.withgoogle.com/docs/index.html
Submission: On November 21 via manual from NZ — Scanned from NZ
Form analysis
0 forms found in the DOMText Content
Content Security Policy * Introduction * Why CSP * Strict CSP * Adopting CSP * FAQ * Resources This documentation is outdated and available for historical reasons only. To learn how to enable strict Content Security Policy in your application, visit web.dev/strict-csp. INTRODUCTION Content Security Policy is a mechanism designed to make applications more secure against common web vulnerabilities, particularly cross-site scripting. It is enabled by setting the Content-Security-Policy HTTP response header. The core functionality of CSP can be divided into three areas: * Requiring that all scripts are safe and trusted by the application owner (ideally by making sure they match an unpredictable identifier specified in the policy called the CSP nonce), * Ensuring that page resources, such as images, stylesheets, or frames, are loaded from trusted sources, * Miscellaneous other security features: preventing the application from being framed by untrusted domains, transparently upgrading all resource requests to HTTPS, and others. By adopting a strict policy, which prevents the loading of untrusted scripts or plugins, an application can add an important defense-in-depth layer against markup injection attacks. This documentation focuses on the XSS mitigation aspect of CSP because XSS is one of the most common and dangerous web vulnerabilities. An application can define a policy by setting the following header: Content-Security-Policy: default-src https:; script-src 'nonce-{random}'; object-src 'none' This policy will require all resources to be loaded over HTTPS, allow only <script> elements with the correct nonce attribute, and prevent loading any plugins. Note: Real policies are a bit more complicated for compatibility and security reasons; see this example. CSP support is available in several popular template systems and frameworks (for example, Closure Templates can automatically add CSP nonces). Several helper tools can assist you in building a secure policy, identifying any necessary markup changes, and monitoring the effects of the policy after deployment. WHAT SHOULD I DO NOW? Adopting a safe CSP policy can be an important security improvement for many applications. To see if it's right for your app, and learn what you need to do to enable CSP, take a look at the following pages: * Why CSP is a short explainer document discussing the benefits of using CSP, and examining when a policy is most useful for an application. * Strict CSP describes the proposed approach for using CSP to defend against XSS. Adopting CSP shows the recommended way to make an application compatible with CSP, including a production-ready policy, example code, and overview of tools which help you deploy a secure policy. * The FAQ discusses common adoption and security issues, including a comparison of the strict CSP approach to traditional policies. * The Resources page contains links to useful tools, code examples, and additional documentation. SITE CONTENTS * Introduction * Why CSP * Strict CSP * Adopting CSP * FAQ * Resources