TL;DR: silent extension update that strips CSP headers under W3C user-priority clause
- Most teams treat CSP as a hard boundary. The CSP3 spec says otherwise: policy should not interfere with add-ons, because the user agent takes priority. An extension can strip your 31 directives without your grandfather ever seeing a consent prompt.
- cside detects browser-runtime behavior after the request has already left your control. When a silently updated extension removes the header you shipped to protect a payment page, that behavior is what triggers the alert, since the report-uri you were counting on never fires once the header is gone.
- The W3C is unlikely to redraft the priority clause on your timeline. So the real decision is whether CSP stays your only client-side defense, or whether you add runtime script observation that still works for the extension a user installed six years ago and forgot about.
When Content Security Policies (CSP) were released, the initial scope was designed to mitigate Cross-Site Scripting (XSS) and malicious client-side injections through client-side fetched resources. Over time, CSP grew and today there are a total of 31 directives with varying levels of support across browsers and 3 different reporting formats.
These headers allow a website owner to define which sources are trusted to fetch JavaScript from. Fonts, stylesheets or iFrames. It also allows defining external connections to exfiltrate data. A properly implemented CSP can prevent unwanted behaviors. But CSP is not that user friendly and has a few major flaws, you can read about that here.
However, should a browser extension be able to quietly remove these headers?
The logic of the specification
"Policy enforced on a resource should not interfere with the operation of user-agent features like add-ons, extensions, or bookmarklets. These kinds of features generally advance the user's priority over page authors, as espoused in [HTML-DESIGN]."
To put this in simple terms, your browser is your client. Your client takes priority over security on the webpage you visit. This is logical. If this was not the case, it is likely that browsers would still do this anyway. Browsers can decide not to do things as specified anyway in today's world. A specification of the w3c is often seen as an end goal met by compromises along the way.
However…
Surely everyone sees the issue here right?
My concern:
"Sure W3C, but my grandfather wouldn't know that by installing an extension he is allowing it to remove essential security features from websites."
This problem stretches further. Many browsers actively update extensions without specific approval or opt-in. That means an extension today can behave wildly differently tomorrow, and you will not be made aware of it.
Unfortunately, throughout my career I have noticed that people do not tend to think about their parents or grandparents when building technology. Unconsciously overlooked or something else - one day we will be old and our kids could do the same to us. Why are we like this?
Browsers are feature machines. Security is a feature. If some serious security concerns arise, eventually something will be done about it through external pressure and outcry. But the priority remains flashy features and security is just not treated as priority 1.
So what is a solution here?
This goes beyond the W3C. It should be part of the broader browser security framework, one that pushes browser vendors to self-regulate and take security seriously.
I'm wondering: why not make this an explicit opt-in?
If an extension at installation, or update, adds the functionality to remove or adjust security headers, make the user aware and approve the behavior.
Client-side security is an interesting problem space, the above subject is just one of many things that is fundamentally wrongly implemented and dangerous. While I raise this as an issue at the W3C level, this is actually a browser designed security issue.
There is a lot more. Protect your customers, try cside.
