meta tag Content Security Policy

[phppup]

Stumbled across this tag

<meta http-equiv="Content-Security-Policy">

and was interested in learning whether the tag is worthwhile, how effective it is, and how to best test its usefulness.

Some reading seemed to indicate that once set, you cannot UNSET or lower restrictiveness, so I was confused as to how to test it appropriately.

Any information, worthwhile links or advice pertaining to using this tag in association with pages that would interact with PHP and JavaScript code would be appreciated.

Thank you.

[kicken]

There is a lot of information about it in the Content-Security-Policy page on MDN. 

Essentially it's yet another way of protecting your site from potential attacks by restricting where various resources like JavaScript code can be loaded from.  For example, if you set a policy of default-src: 'self' then JavaScript can only be run from files that reside under your domain, not as inline scripts or from external domains.  As a result, if you happened to have a cross-site scripting vulnerability in your code an attacker wouldn't be able to inject a <script> tag with inline JS or a reference to an external file, the browser would ignore such tags because the violate the policy.

 

[phppup]

Are inline scripts inherently bad structure?

Is the value gained from the meta tag worth the hassle of re-organizing my JavaScripts? Or can I get the same level of security from other approaches?

I always thought that HTML was the easiest option of a webpage for a malicious actor to exploit.  What makes the HTML meta tag any different?

Edited August 9, 2022 by phppup
Clean up post

[kicken]

Inline scripts are generally to be avoided because they are simply less clean.  Disallowing them however does help reduce the possibility of someone successfully exploiting your site with XSS.  It's typically much more common that an XSS exploit allows an attacker to just embed a <script> tag or on* attribute than it is for them to create a js file on your server.  As such if you have a CSP setup that doesn't allow inline scripts and only allows script files loaded from your server they would have a hard time getting around that.

 

If you're starting out with a new project, I would recommend implementing a CSP and trying to be as strict as you can be about it.  Re-factoring an existing project to adhere to one may be more work than it's really worth (particularly if you're confident you don't have any XSS problems) but that's a calculation you have to make yourself.

[phppup]

It may just be a result of my development. I've found it easier to put JS on the same page as my HTML during development because it simple to see results and make adjustments.

It seemed a little more cumbersome but (until now) I had no reason to avoid inline scripts.

In fact, I've got instances where the JS only worked at the end of a form (ie: event listeners). How are those handled of I introduce the associated file in the HEAD of the HTML?

What about AJAX?

[kicken]

2 hours ago, phppup said:

It seemed a little more cumbersome but (until now) I had no reason to avoid inline scripts.

I've always found it easier to debug JavaScript using the browser's development tools when it's in a separate .js file vs as an inline script.  I've also found it nicer to work on since you don't have a bunch of extra HTML in the way.  The only down side is potential caching issues but keeping the browsers dev tools open with 'Disable cache' enabled fixes that.

 

1 hour ago, phppup said:

In fact, I've got instances where the JS only worked at the end of a form (ie: event listeners). How are those handled of I introduce the associated file in the HEAD of the HTML?

You can link your script files at the end of the document instead of in the head if you want. Due to how my template setup works, that is how my pages are generally structured.  However, the proper way to handle that is to wait for the DOMContentLoaded event before you do anything with the DOM.

window.addEventListener('DOMContentLoaded', function(){
    var form = document.getElementById('yourForm');
    form.addEventListener('submit', function(){
        //...
    });
});

If you're using jQuery, then that's as simple as passing a function to the jQuery function.

jQuery(function($){
    var $form = $('#yourForm');
    $form.submit(function(){
        //...
    });
});

 

2 hours ago, phppup said:

What about AJAX?

What about it?  It doesn't work any differently inline vs external.  If you mean with regards to the CSP, then it is limited as well.  You can set it's limits specifically using connect-src if you want.

[morocco-iceberg]

There are some cases where it is required to work with a strict content security policy, particularly when audits are involved for compliance with vendors. It can be both a useful security measure and a bit of a headache if you also need to maintain third-party scripts that don't comply but you can't remove for various reasons