Content Security Policy
Recommended for all Webtricity websites
CONTENT SECURITY POLICY FAQS
Don't see your question? Send us an email.
If you're familiar with and confident in your understanding of the Content Security Policy specification, then yes, you can author your own CSP and won't have to pay the setup fee.
Unfortunately not, but with good reason. The monthly fee also covers policy violation monitoring and maintenance, necessary when:
- a policy violation is reported and requires investigation
- you need to add something to your website that would violate the current CSP, like a new embedded rating engine or a live chat widget
- there are updates to the CSP spec
The reason we don't offer a way for users to disable or make changes to CSPs is that doing so would defeat part of the purpose of a CSP, which is to disallow new code from being added without your knowledge or permission.
If we did allow users to manage CSPs and an attacker were to gain access to your website account, the attacker could simply disable or modify your CSP to allow their malicious code, rendering the CSP ineffective.
Because all CSP edits are processed by our team, we ensure that each change is manually reviewed for security and legitimacy.
You can verify that the CSP is present by opening your browser's developer tools, loading your website, and looking at the response headers on the initial request.
If there is a header named "content-security-policy" and its value contains "default-src" then a CSP is active on your website.
And if your website looks and functions correctly (i.e., it shows images, the colors look right, the drop-down navigation menus are displaying, etc.), then you'll know that the CSP is working.
Another way to tell is to look at the JavaScript console in your browser's developer tools — if you don't see any red error messages that say "Refused to display/apply/etc." then the website hasn't attempted to do anything that is disallowed by the CSP.
Probably not. We've made adjustments and improvements to our software and the code libraries we use to allow for strict CSPs to be implemented, and we haven't come across anything yet that had to be removed for the CSP.
A CSP is a layer of security that depends on and enhances some of the protections SSL provides (when used properly).
SSL lets you know that the webpage you're viewing wasn't modified by an attacker while in transit.
However, SSL won't protect against these two distinct potential threats:
- A website being modified before it's in transit
- A website loading scripts from a third party or being modified after it's been delivered to you
A CSP responds to these two threats by telling browsers what types of and from which sources they are allowed to load resources when displaying a website.
It's not insecure, but a CSP makes it more secure. The key is that the CSP is a managed policy, meaning it can't be edited without our involvement (meaning any changes to your CSP will have gone through someone who understands the implications of the changes being made).
If someone somehow finds a way to add something unauthorized to the site — like new JavaScript code, a video, or an iframe from a source that isn't already allowed — the CSP will block those things from being loaded by visitors' browsers, and we'll be notified about the attempt.
There are no downsides to adding additional layers of security to your website.
Even if you drive a really safe car, you always drive the speed limit, you come to a complete stop at stop signs, and you're never distracted while driving, it's still a good idea to wear a seatbelt. All of these things reduce the risk of collisions and injuries, and there's no harm in adding as many layers as possible.
Even if you're very careful with your own accounts, your third-party marketing company may not have strong security policies, or the user with access to your accounts may not adhere to them.
It could be as simple as having an unlocked laptop stolen from a car parked in the gym parking lot, with the browser still logged into your Google Analytics account, meaning the person who stole the laptop now has access to your Google Tag Manager account, giving them a way to add new script tags to your website without your knowledge.