Unfortunately, you are the ones responsible of seeing if your threat model is justified or not. Therefore, we cannot simply give a definite "yes" whether we see using the platform as a security threat or not.
However, there are two points that I'd like to expand on:
You seem to be extremely worried about the source code containing vulnerabilities and that ...
@Simon has already provided a fantastic answer, but I'd like to add in response to this point:
there is no possible real warranty that staff from Gitlab cannot investigate the source and find security holes or some sensitive configuration
Configuration does not belong in the repository. Configuration should be combined with code at deployment, not ...
Won't whitelisting unsafe-inline and unsafe-eval kind of defeat the whole CSP?
Yes. A tight CSP will make it harder to exploit XSS by restricting the scripts that can be executed. Using unsafe-inline and unsafe-eval allow to run any script. This is also why they are prefixed by unsafe-, to discourage you from using them in the CSP.
Of course the data: ...
There are multiple options except for Gitlab (including pure Git). Gitlab is an open-source/open code project so that you can install it on your private server, so nobody except your team have access.
Which, raises, I believe, more prominent issue - your staff know security holes or some sensitive configuration and could sell the source code to some third ...
[from comment] ... IE was not working, but, does ie11 even support this header?
According to can i use content security policy there is only partial support in IE11: only the sandbox directive is supported and the header needs to be specified as X-Content-Security-Policy. Thus, no support in IE11 for what you are trying to do.
This is now the default policy for all directives that are absent. This is not as secure as it could be.
Since there is no img-src directive, the value for default-src is used as img-src. This means that images can be loaded from any URL. This doesn't introduce a big security problem, since showing images is relatively benign.
There is also ...
Your policy is perfectly fine (you can paste it into the CSP Evaluator to confirm) -- hashes are a good alternative to nonces, particularly in static applications.
There are two reasons why most of the advice about policies with strict-dynamic focus on nonces rather than hashes:
Applications often dynamically interpolate values inside <script> blocks ...
Inotify monitors directories individually. To monitor a directory tree, you need to monitor each subdirectory, and to attach to new subdirectories when they are added. I'm note sure if it's possible to do this without a race condition.
If you want to log the files that are created in a directory, there are better ways. You can put the files to watch on a ...
This can be happily cached by the application server for days without negatively impacting the CSP nonce protection.
No. The nonce should be unique for every request (nonce = number used once).
I guess the only solution is to use non-cached SSI (server side includes) for the script-tags containing the nonce and combinating that with the nonce in the ...
Sadly, it's not possible.
You can check that with the following HTML snippet where the default CSP directive is set to none (except script-src):
<meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'unsafe-inline'">
<script>window.location = '?' + Math.random();</script>
Since window.location is a non-...
You allow the advertising partner’s code in the context of your page, giving it full access to the DOM and everything on the page. If the script is compromised and you load it there isn’t much you can do. There is however, a way to detect if the script you are including has been altered from a previously known state. This is called Subresource Integrity.
Your question can be answered with a simple test using some local HTML file:
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">
Refused to run ...
If I recall correctly, when HSTS preload was launched, it did not need to have subdomains included.
Now, the requirements state :
Serve all subdomains over HTTPS. In particular, you must support HTTPS
for the www subdomain if a DNS record for that subdomain exists.
Serve an HSTS header on the base domain for HTTPS requests:
The max-age ...
The answer is actually a part of your question:
Adobe Fonts uses inline styles and fonts as data URIs to provide our service, and making exceptions for these negates a lot of the protection provided by a CSP.
As you see, Adobe does not follow best practices when it comes to security. If you would tweak your CSP in order to allow these things, you might ...
The articles on Windows IT Pro Center are in a hierarchical order, and it is expected that it would be unnecessary to repeat the information provided on previous levels. Your answer is three levels up:
Security policy settings
Security policy settings are rules that administrators configure on a
computer or multiple devices for the purpose of ...
There is a CSP directive that prevents this, but it's probably not what you meant:
Why not use a private gitlab instance, this would alleviate any of your concerns!
If your platform is to reach millions of users you could at least have a $5 a month cloud instance to run this on.
But your concern comes from employees/ admins of SaaS platforms you use having ultimate access to your platforms, this would be true of any cloud service ...
In so far as major browser support and working as advertised, then yes CSP nonce is suitable for production use. For cases where business reasons prevent changes to the website then it is still superior to not having a CSP or one that allows all unsafe-inline sources.
However as you hint at, using inline sources should be avoided where possible and nonces ...
The Content-Security-Policy connect-src directive is what you are after. This directive restricts what hosts the fetch method can send requests to.
Here is a minimal proof of concept:
<meta http-equiv="Content-Security-Policy" content="connect-src 'self'">
A good question. CSP controls the behavior of the browser AFTER the HTTP content has already reached the browser. For example which domain images can be loaded from. It provides protection at the application level. Man-in-the-middle (MiTM) attacks on the other hand occur at the transport level, allowing the attacker to change the content including HTTP ...