CSP: rules for the resources that the page loads

Useful to know

Content Security Policy, abbreviated CSP, is a mechanism for setting rules to the browser when working with a single page. Often these rules are sent via a HTTP header. They can restrict where scripts, images, and other resources are loaded. The policy is made up of directives, each having a name and values. For example, the image rule may differ from the script rule because the two types of resources serve different needs. [1]

It is easiest to understand the policy as a described set of permissions. The self value denotes the own origin in the relevant directive. The default-src directive sets the basis for a number of types of resources, while a more specific directive may lay down a separate rule. [1] This does not mean that the shortest policy is always the most appropriate. It is necessary to know what the page actually uses and for what reason. Otherwise, a rule may be strictly in appearance, but unsuitable for the operating interface.

Let's imagine a fictional site with local images, an external font, and a built-in map. Before we write permissions, we can make a simple inventory: which component is needed, which address provides it, and on which pages it is used. If a card is only in the contact page, it is a separate need to display your own logo. Such an inventory helps the security conversation to be specific and not become a promiscuous addition of domains.

The Content-Security-Policy-Report-Only. header exists for testing. It allows monitoring of violations without the relevant policy being imposed. Thus, the team can detect incompatible resources before turning on the blocking mode. [2] Appropriately configured reporting is also required if reports are to be sent. The header name itself does not mean that someone will automatically review the results or make a decision about which resources are justified.

CSP is an additional layer of protection against certain ways to execute unwanted code on the page. It does not negate the need for the application to properly process and output the input data. [1] In a practical review, we can separate two tasks: checking how the application builds the content and checking how the browser implements the policy. This separation makes defects easier to describe. A successfully blocked resource does not need to be presented as proof that every other part of the site is protected.

After the test, good maintenance has a clear owner and a short list of grounds for the permits. When a new external component is added, the team checks to see if it requires a change and if it meets a specific function. It is also useful to keep an example visitor route for re-checking. Thus, the policy is developed together with the site, and each extension has an explainable reason and a verifiable result for the working pages.