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). But as Gitlab is open source/open code project so you can just install it on your private server, so nobody except your team will 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 ...
[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.
MDN - Content Security Policy (CSP) - Browser Compatibility shows what is supported in MSIE and what not. To summarize:
MSIE only supports the sandbox flag
MSIE only supports the old X-Content-Security-Policy header. It does not matter if it is deprecated - MSIE by itself is deprecated too.
Is there any alternative to CSP
There is no general ...
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 ...
CSP frame-ancestors already does what you want.
Content-Security-Policy: frame-ancestors [...] checks the entire ancestor chain. If any parent document doesn't match the source whitelist, your document will not be loaded.
If your chain is top(child(grandchild)), this policy for grandchild would pass:
Content-Security-Policy: frame-ancestors top child
I understand that ideally CSP should be set for text/html responses only.
It does not harm to set it on every other response too, especially if it could be tricked to be rendered in HTML context.
Is it enough to add content security policy (CSP) header to the login page or should I add the header to each & every page?
CSP gets only applied to the ...
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 ...
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 ...
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 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 ...
I wasn't able to find any official reason. But generally, injection of a base tag can be used in HTML injections.
For example, consider that an attacker can only post very limited HTML (but can use base). Depending on the point of injection, they could now hijack existing forms to send the information (eg CSRF tokens, passwords, etc) to their server.
There is a standard for Xml encryption, from w3c. It is complex and has several shortfalls but that will provide some level of interoperability should it be needed
Otherwise,the simplest is to use pgp to encrypt your file and put that into your zip. Pgp incluses an optional compression stage so you don't need to bother with that
Some articles say compression need to be done prior to encryption.
Compression should be done before encryption because encrypted data will not be compressible. So, if you encrypt first then there is no point in trying to compress the encrypted data further.
This happens because the encryption algorithm causes the encrypted data to look like just random ...