Nginx Content Security Policy Example Syntax For Normal Websites

We discussed about  Content Security Policy before –  Content Security Policy for adding report-uri. Readers are complaining that many sites are proving snippets which are throwing odd errors in Nginx, like nginx: [emerg] invalid number of arguments in “add_header”, nginx: [emerg] invalid parameter “self”, nginx: [emerg] unexpected “s”. So, Here is Nginx Content Security Policy Example Syntax For Normal Websites Which Will Not Throw Any Error.

Before Implementing Nginx Content Security Policy Example

You Can Use With Nginx Content Security Policy Example on Normal Website Only the Report Only Function. Honestly, you can not use Content Security Policy with Google AdSense or any Third Party Ads. It is an impractical idea to add header to prevent XSS attack. With so many browsers and devices, except loading webpage from 1 -2 sources it is just not possible. We are giving example of both.

Nginx Content Security Policy Example

Those websites providing wrong syntax for Nginx. This is a common way to add any header on Nginx :

The above will give this output upon curl -I header checking :

In that way, this is a perfect clean Nginx Content Security Policy Example :

You will get all resources on :

… just register and use the tool. Suppose the web software suggested this :

You can make it to this for nginx:

It will avoid this error :

However, with the above some browsers may not allow anything expect text to load. We have tested may ways to only use Nginx Content Security Policy for protecting for XSS on websites with Third Party Ads running, has CDN. It is just not possible. Safari will load webpage without CSS, Images. Even this (notice default-src * unsafe-inline unsafe-eval) :

…forces not to load any Google Ads on Safari.

Nginx Content Security Policy Report Only Example (This is What You Can Use)

We are using this :

If you run :

You will get :

The above is safe for your website as webmaster to apply on whole website. Except reporting it has no action. That method of reporting is not exactly easy though.

Use Content Security Policy Dynamically, Not One Rule For Whole Website

Checkout pages, payment pages needs more security. You can inject the restricted header on the must be under microscope webpages. WordPress /wp-login.php is one such webpage, if you have PHPMyAdmin, that is important to filter. You can use PHP to pass the header.