Content-Security-Policy #94

@bkcsoft commented on GitHub (Dec 2, 2016):

Yes, that should be a class, not inline style :)

@bkcsoft commented on GitHub (Dec 2, 2016): Yes, that should be a class, not inline style :)

GiteaMirror commented

@Eriner commented on GitHub (Dec 11, 2016):

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.

@Eriner commented on GitHub (Dec 11, 2016): 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.

GiteaMirror commented

https://github.com/unrolled/secure#content-security-policy

@denji commented on GitHub (Dec 17, 2016):

https://github.com/awakenetworks/csp

@denji commented on GitHub (Dec 17, 2016): https://github.com/unrolled/secure#content-security-policy * https://github.com/awakenetworks/csp

GiteaMirror commented

@Bwko commented on GitHub (Dec 18, 2016):

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?

@Bwko commented on GitHub (Dec 18, 2016): 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?

GiteaMirror commented

@tboerger commented on GitHub (Dec 18, 2016):

We should get rid of all inline crap.

@tboerger commented on GitHub (Dec 18, 2016): We should get rid of all inline crap.

GiteaMirror commented

@Bwko commented on GitHub (Dec 18, 2016):

@tboerger I'm almost done with that (except for labels) but for tooltips semantic ui needs unsafe-inline 😕

@Bwko commented on GitHub (Dec 18, 2016): @tboerger I'm almost done with that (except for labels) but for tooltips semantic ui needs unsafe-inline :confused:

GiteaMirror commented

@tboerger commented on GitHub (Dec 18, 2016):

Even tooltips can be perfectly done with data attributes and unobtrusive js.

@tboerger commented on GitHub (Dec 18, 2016): Even tooltips can be perfectly done with data attributes and unobtrusive js.

GiteaMirror commented

@hasufell commented on GitHub (Jun 6, 2018):

any news?

@hasufell commented on GitHub (Jun 6, 2018): any news?

GiteaMirror commented

@clarfonthey commented on GitHub (Jun 23, 2018):

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!

@clarfonthey commented on GitHub (Jun 23, 2018): 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!

GiteaMirror commented

@toth-dev commented on GitHub (Jun 23, 2018):

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.

@toth-dev commented on GitHub (Jun 23, 2018): 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.

GiteaMirror commented

@hasufell commented on GitHub (Jun 23, 2018):

@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.

@hasufell commented on GitHub (Jun 23, 2018): @totpet interesting, I tried that too and it seems to work so far, but afais [mozilla observatory](https://observatory.mozilla.org) reports this as -20 score, so it seems to be too lax.

GiteaMirror commented

@clarfonthey commented on GitHub (Jun 23, 2018):

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.

@clarfonthey commented on GitHub (Jun 23, 2018): 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.

GiteaMirror commented

@toth-dev commented on GitHub (Jun 24, 2018):

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')

@toth-dev commented on GitHub (Jun 24, 2018): 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'`)

GiteaMirror commented

@stale[bot] commented on GitHub (Jan 21, 2019):

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.

@stale[bot] commented on GitHub (Jan 21, 2019): 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.

GiteaMirror commented

@Oreolek commented on GitHub (Jul 7, 2019):

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.

@Oreolek commented on GitHub (Jul 7, 2019): 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.

GiteaMirror commented

@noplanman commented on GitHub (Sep 4, 2019):

I'm running into this issue too, would be great to get this built-in 👌

@noplanman commented on GitHub (Sep 4, 2019): I'm running into this issue too, would be great to get this built-in 👌

GiteaMirror commented

@MetroWind commented on GitHub (Nov 20, 2019):

New user here. I’d 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 commented on GitHub (Nov 20, 2019): New user here. I’d 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.

GiteaMirror commented

@hasufell commented on GitHub (Mar 27, 2020):

@MetroWind to which header?

@hasufell commented on GitHub (Mar 27, 2020): @MetroWind to which header?

GiteaMirror commented

@dpertin commented on GitHub (Mar 30, 2020):

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.

@dpertin commented on GitHub (Mar 30, 2020): I used the [Mozilla Laboratory](https://addons.mozilla.org/en-US/firefox/addon/laboratory-by-mozilla/) 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](https://csp-evaluator.withgoogle.com) 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](https://scotthelme.co.uk/csp-nonce-support-in-nginx/).

GiteaMirror commented

@SuperSandro2000 commented on GitHub (Apr 2, 2020):

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;

@SuperSandro2000 commented on GitHub (Apr 2, 2020): `` 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; ``

GiteaMirror commented

@tomposmiko commented on GitHub (Jul 6, 2020):

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 commented on GitHub (Jul 6, 2020): 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.

GiteaMirror commented

2025-11-02 03:08:37 -06:00

@alexanderadam commented on GitHub (Jul 6, 2020):

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.

@alexanderadam commented on GitHub (Jul 6, 2020): > 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](https://www.bountysource.com/issues/39614247-content-security-policy), 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.

GiteaMirror commented

@SuperSandro2000 commented on GitHub (Jul 6, 2020):

that a feature or a bugfix will be implemented on one point.

Not that it is different if your paying for software 😆

@SuperSandro2000 commented on GitHub (Jul 6, 2020): > that a feature or a bugfix will be implemented on one point. Not that it is different if your paying for software :laughing:

GiteaMirror commented

@Crocmagnon commented on GitHub (Apr 24, 2021):

Could we at least make gitea serve its own CSP? IMO it's the responsibility of the app to know what it needs to load and from where. Even if we're not going to implement a safe CSP in the first iteration, I'd suggest starting by providing one and then refining it when we clean the inlines and evals.

An even easier first step might be to provide a CSP in the documentation that admins can set on their proxies and after some time implementing it in the code.

@Crocmagnon commented on GitHub (Apr 24, 2021): Could we at least make gitea serve its own CSP? IMO it's the responsibility of the app to know what it needs to load and from where. Even if we're not going to implement a safe CSP in the first iteration, I'd suggest starting by providing one and then refining it when we clean the inlines and evals. An even easier first step might be to provide a CSP in the documentation that admins can set on their proxies and after some time implementing it in the code.

GiteaMirror commented

@ix5 commented on GitHub (Feb 23, 2022):

Just as a current (2022, gitea 1.16.1) reference point, I have the following policy implemented and haven't had any (gitea-related) pings on my report-uri:

Content-Security-Policy-Report-Only: "default-src 'self'; connect-src 'self'; font-src 'self' data:; form-action 'self'; img-src 'self' https: data:; object-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; worker-src 'self';"

Edit: Amended with below comment (which I can confirm):
Content-Security-Policy-Report-Only "default-src 'self'; connect-src 'self'; font-src 'self' data:; form-action 'self'; img-src 'self' https: data:; manifest-src 'self' data:; object-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; worker-src 'self';"

Admins who would like to tighten that policy up (esp. img-src https) should be free to do so, but I think this is a good baseline.

@ix5 commented on GitHub (Feb 23, 2022): Just as a current (2022, gitea 1.16.1) reference point, I have the following policy implemented and haven't had any (`gitea`-related) pings on my `report-uri`: `Content-Security-Policy-Report-Only: "default-src 'self'; connect-src 'self'; font-src 'self' data:; form-action 'self'; img-src 'self' https: data:; object-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; worker-src 'self';"` **Edit:** Amended with below comment (which I can confirm): `Content-Security-Policy-Report-Only "default-src 'self'; connect-src 'self'; font-src 'self' data:; form-action 'self'; img-src 'self' https: data:; manifest-src 'self' data:; object-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; worker-src 'self';"` Admins who would like to tighten that policy up (esp. `img-src https`) should be free to do so, but I think this is a good baseline.

GiteaMirror commented

@tepozoa commented on GitHub (Mar 30, 2022):

Gitea 1.16.5
Chrome 100.0.4896.60

Generally following the above, I ran into Chrome refusing to load a manifest-src base64 encoded element as it wasn't explicitly allowed to use data: and was inheriting default-src attributes. Adding manifest-src 'self' data:; onto the above solved that Chrome error.

@tepozoa commented on GitHub (Mar 30, 2022): - Gitea 1.16.5 - Chrome 100.0.4896.60 Generally following the above, I ran into Chrome refusing to load a `manifest-src` base64 encoded element as it wasn't explicitly allowed to use `data:` and was inheriting `default-src` attributes. Adding `manifest-src 'self' data:;` onto the above solved that Chrome error.

GiteaMirror commented

@silverwind commented on GitHub (Apr 26, 2023):

script-src: unsafe-inline will probably required indefinitely. There are techniques that can only work with inline script like synchronously altering DOM during rendering to avoid content pop-in, so I see it as a requirement for a ideal experience. I made an attempt to remove inline script in https://github.com/go-gitea/gitea/pull/21429, but it was not well received as it's quite a hack.

We should put out a CSP recommendation in the docs as a guidline on how to set up the most strict CSP possible for gitea to work, but I don't see anything else to be done here.

@silverwind commented on GitHub (Apr 26, 2023): `script-src: unsafe-inline` will probably required indefinitely. There are techniques that can only work with inline script like synchronously altering DOM during rendering to avoid content pop-in, so I see it as a requirement for a ideal experience. I made an attempt to remove inline script in https://github.com/go-gitea/gitea/pull/21429, but it was not well received as it's quite a hack. We should put out a CSP recommendation in the docs as a guidline on how to set up the most strict CSP possible for gitea to work, but I don't see anything else to be done here.

GiteaMirror commented

@clarfonthey commented on GitHub (Apr 26, 2023):

I'm not 100% sure of the details, but surely simply hashing the critical JS would be a solution here? CSP supports this, and it means you'd be able to say that these scripts could be run without anything else being allowed. The hash might change between releases, but I don't imagine that being difficult for folks to deal with if they really care that much over using unsafe-inline.

IMHO the most important aspect of this would be to have similar docs recommending a CSP header for gitea, or having gitea output one itself, even if it does include unsafe-inline. Could this issue be kept open until that is finished?

@clarfonthey commented on GitHub (Apr 26, 2023): I'm not 100% sure of the details, but surely simply hashing the critical JS would be a solution here? CSP supports this, and it means you'd be able to say that these scripts could be run without anything else being allowed. The hash might change between releases, but I don't imagine that being difficult for folks to deal with if they really care that much over using `unsafe-inline`. IMHO the most important aspect of this would be to have similar docs recommending a CSP header for gitea, or having gitea output one itself, even if it does include `unsafe-inline`. Could this issue be kept open until that is finished?

GiteaMirror commented

@silverwind commented on GitHub (Apr 26, 2023):

Guess we can keep open for docs.

hashing the critical JS

What technique is that? Any more info?

@silverwind commented on GitHub (Apr 26, 2023): Guess we can keep open for docs. > hashing the critical JS What technique is that? Any more info?

GiteaMirror commented

@clarfonthey commented on GitHub (Apr 26, 2023):

MDN has you covered: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src

Essentially, you can add sha256-(hash) to the list of allowed sources in the CSP header.

@clarfonthey commented on GitHub (Apr 26, 2023): MDN has you covered: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src Essentially, you can add `sha256-(hash)` to the list of allowed sources in the CSP header.

GiteaMirror commented

@silverwind commented on GitHub (Apr 26, 2023):

Hmm I guess we could set a static nonce on all our inline scripts and CSP could be recommended to use that nonce. It won't be a hash as it needs to work across upgrades.

@silverwind commented on GitHub (Apr 26, 2023): Hmm I guess we could set a static `nonce` on all our inline scripts and CSP could be recommended to use that nonce. It won't be a hash as it needs to work across upgrades.

GiteaMirror commented

@jotoho commented on GitHub (Apr 26, 2023):

If Gitea emitted the CSP-header itself, it could dynamically calculate the hashes of the inline scripts it sends, couldn't it?

I wouldn't be surprised if browsers or the standardization committees implement additional measures (in the future if they haven't already) to prevent usage of nonces that are used more than once.

@jotoho commented on GitHub (Apr 26, 2023): If Gitea emitted the CSP-header itself, it could dynamically calculate the hashes of the inline scripts it sends, couldn't it? I wouldn't be surprised if browsers or the standardization committees implement additional measures (in the future if they haven't already) to prevent usage of nonces that are used more than once.

GiteaMirror commented

@tepozoa commented on GitHub (Apr 26, 2023):

If you're running other resource paths on your frontend and need CSP policies to accommodate their needs, having Gitea generate a full header could be problematic. I found this issue discussing the spec outlining that multiple headers are not to be sent by a server though, but if they are they are evaluated as individuals and not a combined directive.

https://github.com/w3c/webappsec-csp/issues/215

Given what I read in the above, a toggle in app.ini to allow an admin to disable Gitea from generating it's own CSP header has to be present, as the Gitea header may conflict with what they're running in their reverse proxy layer.

@tepozoa commented on GitHub (Apr 26, 2023): If you're running other resource paths on your frontend and need CSP policies to accommodate their needs, having Gitea generate a full header could be problematic. I found this issue discussing the spec outlining that multiple headers are not to be sent by a server though, but if they are they are evaluated as individuals and not a combined directive. * https://github.com/w3c/webappsec-csp/issues/215 Given what I read in the above, a toggle in app.ini to allow an admin to disable Gitea from generating it's own CSP header has to be present, as the Gitea header may conflict with what they're running in their reverse proxy layer.

GiteaMirror commented

@silverwind commented on GitHub (Apr 26, 2023):

Yes, own CSP header is problematic when reverse proxies "Add" instead of "Replace" the header, which I think is the most common configuration. So I think we should just put out a recommendation in docs initially.

Also, I do not see inline scripts as the grave security problem that some sites make it out to be. If everything is first-party, a inline script is equivalent to a url-sourced script in terms of security. I would not recommend running third-party scripts on Gitea anyways.

@silverwind commented on GitHub (Apr 26, 2023): Yes, own CSP header is problematic when reverse proxies "Add" instead of "Replace" the header, which I think is the most common configuration. So I think we should just put out a recommendation in docs initially. Also, I do not see inline scripts as the grave security problem that some sites make it out to be. If everything is first-party, a inline script is equivalent to a url-sourced script in terms of security. I would not recommend running third-party scripts on Gitea anyways.

GiteaMirror commented

@clarfonthey commented on GitHub (Apr 26, 2023):

The main benefit of disallowing inline scripts is to proactively prevent XSS and other vulnerabilities from working even if someone manages to get a script tag in the DOM. I agree that the threat model is probably overprotective in some cases, but it's not just about whether there's an external script or not.

@clarfonthey commented on GitHub (Apr 26, 2023): The main benefit of disallowing inline scripts is to proactively prevent XSS and other vulnerabilities from working even if someone manages to get a script tag in the DOM. I agree that the threat model is probably overprotective in some cases, but it's not just about whether there's an external script or not.

GiteaMirror commented

@silverwind commented on GitHub (Apr 26, 2023):

Reading MDN nonce it does seem something that would be easy to support, just generate a random number per HTML request and add it to all resource tags (inline or not).

If we set CSP ourselves in gitea, it will need extensive configurability so users can include 3rd party resources and the like, e.g. a format in config like {"script-src": ["https://example.com"]} to define additional directives.

@silverwind commented on GitHub (Apr 26, 2023): Reading [MDN nonce](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script#nonce) it does seem something that would be easy to support, just generate a random number per HTML request and add it to all resource tags (inline or not). If we set CSP ourselves in gitea, it will need extensive configurability so users can include 3rd party resources and the like, e.g. a format in config like `{"script-src": ["https://example.com"]}` to define additional directives.

GiteaMirror commented

@nicheosala commented on GitHub (Feb 8, 2024):

I'm trying to remove inline JS scripts from Gitea, so that we can avoid script-src: 'unsafe-inline' in CSP.

My main problem is the inline script in templates/base/head_script.tmpl: does anyone have a any idea how to move it to a separate JS file? It is obtained mixing Go templates and Javascript.

I'm not an expert on Go templates and can't find a solution to the above problem. The other inline scripts are not many and they do not mix templates and Javascript. I can list them using VS Code (don't consider the ones that start with <script src, they are fine):

@nicheosala commented on GitHub (Feb 8, 2024): I'm trying to remove inline JS scripts from Gitea, so that we can avoid `script-src: 'unsafe-inline'` in CSP. My main problem is the inline script in [templates/base/head_script.tmpl](https://github.com/go-gitea/gitea/blob/main/templates/base/head_script.tmpl): does anyone have a any idea how to move it to a separate JS file? It is obtained mixing Go templates and Javascript. I'm not an expert on Go templates and can't find a solution to the above problem. The other inline scripts are not many and they do not mix templates and Javascript. I can list them using VS Code (don't consider the ones that start with `<script src`, they are fine): ![inline_scripts](https://github.com/go-gitea/gitea/assets/48255219/feea5072-7958-46c7-ac9e-71c022e340fc)

GiteaMirror commented

@wxiaoguang commented on GitHub (Feb 9, 2024):

I'm trying to remove inline JS scripts from Gitea, so that we can avoid script-src: 'unsafe-inline' in CSP.

My main problem is the inline script in templates/base/head_script.tmpl: does anyone have a any idea how to move it to a separate JS file? It is obtained mixing Go templates and Javascript.

As one of the people who do a lot of Gitea frontend refactoring works, I would say that avoiding inline <script> is not possible at the moment -- at least, very difficult. Actually head_script.tmpl is the easiest one, it could be replaced by some data attribute tags. But, the real blockers are some other <script> blocks which heavily depend on the JS code in page.

@wxiaoguang commented on GitHub (Feb 9, 2024): > I'm trying to remove inline JS scripts from Gitea, so that we can avoid `script-src: 'unsafe-inline'` in CSP. > > My main problem is the inline script in [templates/base/head_script.tmpl](https://github.com/go-gitea/gitea/blob/main/templates/base/head_script.tmpl): does anyone have a any idea how to move it to a separate JS file? It is obtained mixing Go templates and Javascript. As one of the people who do a lot of Gitea frontend refactoring works, I would say that avoiding inline `<script>` is not possible at the moment -- at least, very difficult. Actually `head_script.tmpl` is the easiest one, it could be replaced by some data attribute tags. But, the real blockers are some other `<script>` blocks which heavily depend on the JS code in page.

GiteaMirror commented

@nicheosala commented on GitHub (Feb 10, 2024):

Thank you @wxiaoguang. I think that any reduction of inline scripts is useful for the security of Gitea, although this is an objective often overlooked in favor of others. Maybe I'm particularly sensitive, since the cybersecurity professor just taught us how to carry out XSS attacks 😂

I'll try to study the Gitea code better (and the Go language and its templates) and help out.

@nicheosala commented on GitHub (Feb 10, 2024): Thank you @wxiaoguang. I think that any reduction of inline scripts is useful for the security of Gitea, although this is an objective often overlooked in favor of others. Maybe I'm particularly sensitive, since the cybersecurity professor just taught us how to carry out XSS attacks 😂 I'll try to study the Gitea code better (and the Go language and its templates) and help out.

GiteaMirror commented

@silverwind commented on GitHub (Mar 23, 2024):

Inline scripts can be exempted from CSP by adding a nonce

Also, I think there is nothing preventing us from serving a 1st-party CSP. Load balancers can always override or extend it.

@silverwind commented on GitHub (Mar 23, 2024): Inline scripts can be exempted from CSP by adding a [`nonce`](https://content-security-policy.com/nonce/) Also, I think there is nothing preventing us from serving a 1st-party CSP. Load balancers can always override or extend it.

GiteaMirror commented

@georglauterbach commented on GitHub (Jul 3, 2025):

Using scripts with NONCEs would indeed be a viable option but requires work from Gitea's side. It is probably worthwhile, though, to invest in the CSP header, especially because it is widely adopted and performs relatively well. Moreover, other headers depend on the CSP for extended functionality.

Using script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; is not regarded safe and should be changed.

@georglauterbach commented on GitHub (Jul 3, 2025): Using scripts with NONCEs would indeed be a viable option but requires work from Gitea's side. It is probably worthwhile, though, to invest in the CSP header, especially because it is widely adopted and performs relatively well. Moreover, other headers depend on the CSP for extended functionality. Using `script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';` is not regarded safe and should be changed.

GiteaMirror commented

@wxiaoguang commented on GitHub (Jul 4, 2025):

Actually there is another blocker: htmx. For example: user can inject hx- attributes to an element and trigger htmx call.

Do you have ideas about how to add "script nonce" to htmx elements correctly? @yardenshoham

@wxiaoguang commented on GitHub (Jul 4, 2025): Actually there is another blocker: htmx. For example: user can inject `hx-` attributes to an element and trigger htmx call. Do you have ideas about how to add "script nonce" to htmx elements correctly? @yardenshoham

GiteaMirror commented

@yardenshoham commented on GitHub (Jul 4, 2025):

There is htmx.config.inlineScriptNonce from https://htmx.org/reference/:

defaults to '', meaning that no nonce will be added to inline scripts

If htmx becomes the only blocker, I will solve it.

@yardenshoham commented on GitHub (Jul 4, 2025): There is `htmx.config.inlineScriptNonce` from https://htmx.org/reference/: > defaults to '', meaning that no nonce will be added to inline scripts --- If htmx becomes the only blocker, I will solve it.

GiteaMirror commented

@wxiaoguang commented on GitHub (Jul 4, 2025):

If htmx becomes the only blocker, I will solve it.

If you can resolve htmx, then I can manage to bring CSP nonce protection into Gitea. Then this issue can be closed.

After looking into "inlineScriptNonce", I guess it isn't what we need. It only adds "nonce" attribute to returned HTML content, but it doesn't protect the rendered content.

For example (https://github.com/go-gitea/gitea/issues/305#issuecomment-3034111611): user can inject hx- attributes to an element and trigger htmx call. I think HTMX should prevent such injected code from running by checking nonce. Otherwise attackers can inject hx- contents to call any backend endpoint (for example: edit something, delete something, or change permissions)

@wxiaoguang commented on GitHub (Jul 4, 2025): > If htmx becomes the only blocker, I will solve it. If you can resolve htmx, then I can manage to bring CSP nonce protection into Gitea. Then this issue can be closed. ---- After looking into "inlineScriptNonce", I guess it isn't what we need. It only adds "nonce" attribute to returned HTML content, but it doesn't protect the rendered content. For example (https://github.com/go-gitea/gitea/issues/305#issuecomment-3034111611): user can inject `hx-` attributes to an element and trigger htmx call. I think HTMX should prevent such injected code from running by checking nonce. Otherwise attackers can inject `hx-` contents to call any backend endpoint (for example: edit something, delete something, or change permissions)

GiteaMirror commented

@yardenshoham commented on GitHub (Jul 5, 2025):

I did some research. The best solution, I think, is this htmx extension. However, I don't know enough about Gitea to be sure about it. I feel like it would be a good fit for your nonce plan. Do you agree?

@yardenshoham commented on GitHub (Jul 5, 2025): I did some research. The best solution, I think, is this [htmx extension](https://github.com/MichaelWest22/htmx-extensions/blob/main/src/safe-nonce/README.md). However, I don't know enough about Gitea to be sure about it. I feel like it would be a good fit for your nonce plan. Do you agree?

GiteaMirror commented

@wxiaoguang commented on GitHub (Jul 6, 2025):

Does that extension "protect the rendered content" (to prevent attacker injected hx- contents from running) ? It seems that it also only "only adds 'nonce' attribute to returned HTML content"

@wxiaoguang commented on GitHub (Jul 6, 2025): Does that extension "protect the rendered content" (to prevent attacker injected `hx-` contents from running) ? It seems that it also only "only adds 'nonce' attribute to returned HTML content"

GiteaMirror commented

@yardenshoham commented on GitHub (Jul 28, 2025):

So should we do this or https://github.com/go-gitea/gitea/issues/35059?

@yardenshoham commented on GitHub (Jul 28, 2025): So should we do this or https://github.com/go-gitea/gitea/issues/35059?

GiteaMirror commented

@wxiaoguang commented on GitHub (Jul 29, 2025):

So should we do this or #35059?

Sorry I don't understand what “this” / "or" mean ... I think we should do both (use CSP, remove htmx).

@wxiaoguang commented on GitHub (Jul 29, 2025): > So should we do this or [#35059](https://github.com/go-gitea/gitea/issues/35059)? Sorry I don't understand what “this” / "or" mean ... I think we should do both (use CSP, remove htmx).

GiteaMirror commented

@yardenshoham commented on GitHub (Jul 29, 2025):

I meant should we try to implement CSP with htmx or remove htmx? I understand your answer is remove htmx.

@yardenshoham commented on GitHub (Jul 29, 2025): I meant should we try to implement CSP with htmx or remove htmx? I understand your answer is remove htmx.

GiteaMirror commented