There seems to be a bunch of inline scripts or style rules such as this that don't play nice with CSP. These should be replaced by a CSS class.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Analytic tools CSP Evaluator
Yes, that should be a class, not inline style :)
As a note: report-uri
is a CSP directive that informs the browser where to report violations. Something to consider is providing/setting this directive and ingesting it into gitea to make it available to administrators.
I'm currently implementing a Content-Security-Policy but we need style-src: unsafe-inline & script-src: unsafe-eval for semantic ui & jquery datetimepicker.
@bamboleeeero-bamboleeeero any advice on this?
We should get rid of all inline crap.
@tboerger I'm almost done with that (except for labels) but for tooltips semantic ui needs unsafe-inline :confused:
Even tooltips can be perfectly done with data attributes and unobtrusive js.
any news?
Personally, I would appreciate at least adding a content-security-policy header to Gitea, slowly making it more strict as changes are made. At least things like form-action
and frame-ancestors
would be nice, which are doable now.
I'd be willing to work on this within the next few days if someone more-acquainted with the codebase isn't up to it!
I'm adding this CSP with nginx:
default-src 'none'; base-uri 'none'; manifest-src 'self'; img-src 'self' data:; font-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; connect-src 'self'; form-action 'self'
Everything seems to work with this.
@totpet interesting, I tried that too and it seems to work so far, but afais mozilla observatory reports this as -20 score, so it seems to be too lax.
As I said, things like frame-ancestors
and form-action
are really important parts of CSP that we could add for existing gitea. Adding unsafe-inline
and unsafe-eval
to JavaScript are really bad though, and that pretty much negates everything else.
My policy broke the embedded pdf viewer, because it is loaded as an iframe, and frame-src
falls back to default-src
, adding this fixes the problem: frame-src 'self'; frame-ancestors 'self'
(frame-ancestors
only needs 'default'
inside vendor/plugins/pdfjs/web/
, for other locations it can be set to 'none'
)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
Any news on this? Keep in mind the "Gitea behind a reverse proxy" case where Gitea won't be able to change CSP header dynamically.
I'm running into this issue too, would be great to get this built-in 馃憣
New user here. I鈥檇 also love to see this sorted out. Beside inlines, I think there are also some evals, because I had to add unsafe-eval
to my CSP header for that activity matrix thingy in the dashboard page to show up.
@MetroWind to which header?
I used the Mozilla Laboratory to generate the following CSP:
default-src 'none'; connect-src 'self'; font-src 'self' data:; form-action 'self'; img-src 'self' https://ga-beacon.appspot.com https://raw.githubusercontent.com https://secure.gravatar.com https://sourcethemes.com; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; worker-src 'self';
Everything seems to work with nginx
, but the Google CSP Evaluator notifies a high-priority issue due to the use of 'unsafe-inline' in script-src
. I'd love to see all those inline scripts either externalized, or whitelisted by supporting nonces as proposed here.
img-src 'self' https://ga-beacon.appspot.com https://raw.githubusercontent.com https://secure.gravatar.com https://sourcethemes.com;
This should probably be more like:
img-src 'self' https://raw.githubusercontent.com https://secure.gravatar.com;
Can we count on fixing this issue ever?
I'm wondering if it will ever happen or we should plan with not fixing it ever.
Can we count on fixing this issue ever?
I'm wondering if it will ever happen or we should plan with not fixing it ever.
@tomposmiko most free softwares don't have dedicated developers who are able to make a living by working on them. Meaning, that you can not rely that a feature or a bugfix will be implemented on one point. It is also important that you understand, that this is not specific to gitea, however.
On the plus side, you can usually implement those things by yourself or pay someone to do it.
If I'm not mistaken, this issue wasn't important enough for anyone here, to pay anything, however.
And it wasn't important enough to anyone to invest their valuable time fixing this issue neither.
Now it should be clear, that it would need clairvoyant abilities to answer your question properly. Because this is _not_ a commercial product that can afford ensuring due dates for features or bugfixes reliably.
that a feature or a bugfix will be implemented on one point.
Not that it is different if your paying for software :laughing:
Most helpful comment
Not that it is different if your paying for software :laughing: