Security is a way of life.

Welcome to the brand new "Like aPill" series. In this series, I will try to look at the topics in the most brief, fastest and best practice way possible.

In this article, we will examine Content Security Policy (CSP), Same Origin Policy (SOP) and Cross Origin Request Sharing (COSR).

CSP – Content Security Policy

What is CSP – Content Security Policy?

Content Security Policy is a set of policies through which we can send certain commands to the web browsers of users visiting our web application or a website for security purposes.

It is possible to prevent XSS (Cross-Site Scripting) attacks, frame injection, clickjacking, Protocol Downgrading, etc., thanks to CSP. However, there is a very important point here. CSP works only in browsers that support it. Again, attacks can be made over a browser without support.

CSP offers us an additional layer of security. Although it alone is not sufficient for the security of our system, it can be a very useful security layer with the correct configuration.

Basically, an approach known as whitelist is used in CSP, where only those allowed can pass while defining the rule.

There are 3 versions of CSP announced to date and 2 versions published.

  • CSP 1
  • CSP 2
  • CSP 3 (Under Construction)

CSP - Why is there Content Security Policy?

The reason CSP exists is to create a certain set of rules to prevent malicious attackers from finding vulnerability or exploiting our web application and transmit these rules to the user's web browser.

CSP - How Does Content Security Policy Work?

At the beginning of our article, we mentioned that it works with whitelist logic. Now let's open this up a little more.

Thanks to the whitelist we will create, we will only prevent the operation of the way we allow or accept, and the use of those we do not allow. It will be enough to specify what these resources are in the CSP instructions we send along with the HTTP responses.

In order to understand in more detail how the Content Security Policy works, it will be useful to know what the browser behaves in the background when going to a website. Therefore, you can click here to read the related article.

When we look at it with an attackers' eye;

When going to a website, our browser finds the IP address through the URL we entered and makes a request to the server we want to go to, using the GET method (if we entered the address we want to go directly to the url). If the place we want to go is also available on the relevant server, the http 200 status code is returned and the text of the page is sent with the GET method. If the page does not exist on the corresponding server, an HTTP packet with status code 404 is sent.

Our crawler starts to parse other requests (CSS, Js, images, etc.) by examining the source code of the incoming page at this stage. At this stage, vulnerability arises in systems where output validition and input filtering are not used. The browser will take all requests as it is and download them to the device's temp folder. Therefore, it will be possible for harmful files to be transmitted to the visitors of the site. Running CSP at this stage will prevent this. However, I want to repeat. CSP will not work in browsers without CSP support.

We mentioned that we send CSP via headers. Let's share an example if you ask how the CSP header works:

script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:;
object-src 'none';
base-uri 'none';

content-security-policy: default-src 'self' 'unsafe-inline' * *; script-src 'self' 'unsafe-inline' * *; style-src 'self' 'unsafe-inline'; font-src 'self'; img-src 'self' data: blob: * * *; object-src 'none'; frame-ancestors 'self'; base-uri 'self'; frame-src 'self'; connect-src 'self'

Let's take a closer look at what we can do with CSP headers. The values we have briefly given below allow downloads from all sources by default. For example, loading styles from any source will be allowed unless a value is specified for style.src. We can realize how dangerous it is.















What if?

Now let's look at the tricks. ;)

  • CSP must be defined specifically for each page. This policy should be sent in the http response of the page where it is defined.
  • In this way, instead of setting the same policy for each page, it will be possible to make adjustments to meet the specific needs of each page.
  • While defining the directives, we can only specify the hostname or scheme or FQDN.
  • CSP allows us to use some special keywords when defining the source. For example none, self. However, when using them, we must write them in single quotes.
  • In cases where headers cannot be intervened, we can also edit CSP as a meta tag.
  • However, some special directives cannot be used when defining as meta tags. It is recommended to pay attention to them.
  • Nonces should be rebuilt for each request, should not be repetitive in itself and should be unpredictably powerful. Otherwise, a security vulnerability will occur.

So, can't CSP ByPassed? The answer to this question is unfortunately far from being a clear no for any technology. Of course, nothing can be saved from hackers, and this cannot be saved either.

In an article published by Google (you can access the article by clicking here), 3 common methods identified for CSP bypass were analyzed. In these methods, CSP ByPass - Open Redirection, CSP ByPass - Insecure JSONP Endpoint and CSP ByPass - AngularJS CSP Compability Mode.

SOP – Same Origin Policy

What is SOP – Same Origin Policy?

Same Origin Policy (SOP) Protocol is a security protocol that controls domain and port information.

SOP is a security layer that allows resources in the same origin to access each other. According to the SOP, it is to provide security by restricting the communication of resources with different protocols, domains and ports with each other. For example, let's say we are trying to go to Since HTTPS connection will be used, it will be checked whether access is made with the following information.

Protokol: HTTPS
Port: 443

If even one of the above data is different from the data returned upon the request made by the browser, the response will not be processed thanks to SOP.

SOP - Why Is Same Origin Policy?

When we enter a website, those sites leave us cookies via the browser. It is the same as long as the location where the cookies are stored is not changed. You can read the article about the importance of cookie in terms of security by clicking here.

The person who owns the cookie can enter the site without any verification. Let's add the information that JavaScript can access the cookie. When we add that the browser can run code on our device, the alarm bells go off. As a result of their combination, the answer to the question why does SOP exist?

Today, almost all modern browsers accept this policy and give permissions accordingly.

SOP - How Does Same Origin Policy Work?

We have a resource that explains how SOP works in stages. First, let's quote and analyze it.

  1. By loading a script from source B, it can be run in its own context.
  2. It cannot access the raw code, source code of a script at source B.
  3. Can upload CSSs from B source.
  4. It cannot access the raw-text state of CSSs in source B.
  5. Can include a page in source B to itself with iframe.
  6. It cannot access the DOM of this iframe that it loads from source B.
  7. Can upload an image from source B.
  8. It cannot access the bits of this image uploaded from source B.
  9. It can run a video from source B.
  10. It cannot capture and recreate images of this video uploaded from source B.

When we look at the above flow, it will not be possible to change the domain of a website and access the elements on the site.

What if?

Now let's look at the tricks.

  • We can call XMLHTTPRequest to a different origin, but we don't get a response.
  • If the same origin is called, we can read the answer.
  • If the source we call is in the same orig, a custom header can be added.
  • Verify whether the origin of the site from which JSONP is being called is reliable. At the same time, making this request over a secure channel such as SSL will also be an extra security measure.

COSR – Cross Origin Request Sharing

Cross Origin Request Sharing, namely CORS, is a bit related to our previous topic. As the name suggests, it is resource sharing between different centers. We can specify it as stretching the limitation of resource sharing on different domain names.

We mentioned that browsers prevent the stealing of cookie information of other sites opened in the same browser of a malicious domain thanks to SOP. Sometimes the need to allow the web applications we develop to access from different domains may arise. In such cases, the CORS policy comes into play.

Let's make this concrete with an example. Let's assume that we pull data by creating XMLHTTPRequest from the API service of for some modules on to work. You may notice that there are different domains here. SOP will not accept this, under normal circumstances, as the domains in the incoming request and the returned response will be different from each other. If a policy is specified with CORS, we can make the SOP accept it.

-Additional information-
If you want to check the CSP of the websites:
If you need help editing CSP: