X-Content-Type-Options header (and others) #13907

New Issue

GiteaMirror · 2025-11-02T10:56:53-06:00

GiteaMirror commented

2025-11-02 10:56:53 -06:00

Originally created by @ArchangeGabriel on GitHub (Jan 3, 2025).

Feature Description

Hi there,

While reviewing my nginx and gitea configuration, I see that gitea is still far from optimal regarding emitted HTTP headers. And I could not find any place discussing this particular header (the one in the title, see after for others).

If you do a quick security headers check (e.g. https://securityheaders.com/?q=https%3A%2F%2Fgitea.com%2Fexplore%2Frepos&hide=on&followRedirects=on), you will see that almost everything is red (see screenshot below).

There is a very easy one (at least it seems to me), the one in the title. Only one possible value, as explained here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
https://scotthelme.co.uk/hardening-your-http-response-headers/#x-content-type-options

If you wonder why that should be set, this is likely the best answer I could find: https://stackoverflow.com/a/37201425/3845564

I think I can provide a PR for this, based on how X-Frame-Options currently works (i.e. adapting https://github.com/go-gitea/gitea/pull/30256/files).

Now regarding that last one, it has been obsoleted https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options. The new solution is CSP but I see there is already https://github.com/go-gitea/gitea/issues/305 on the topic, and I guess that moving to the new iframe handling should be done as part of it.

(Note: Strict-Transport-Security and Referrer-Policy are not to be set by Gitea, this is admin policy and likely configured more globally)

Regards.

Screenshots

Originally created by @ArchangeGabriel on GitHub (Jan 3, 2025). ### Feature Description Hi there, While reviewing my nginx and gitea configuration, I see that gitea is still far from optimal regarding emitted HTTP headers. And I could not find any place discussing this particular header (the one in the title, see after for others). If you do a quick security headers check (e.g. https://securityheaders.com/?q=https%3A%2F%2Fgitea.com%2Fexplore%2Frepos&hide=on&followRedirects=on), you will see that almost everything is red (see screenshot below). There is a very easy one (at least it seems to me), the one in the title. Only one possible value, as explained here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options https://scotthelme.co.uk/hardening-your-http-response-headers/#x-content-type-options If you wonder why that should be set, this is likely the best answer I could find: https://stackoverflow.com/a/37201425/3845564 I think I can provide a PR for this, based on how X-Frame-Options currently works (i.e. adapting https://github.com/go-gitea/gitea/pull/30256/files). Now regarding that last one, it has been obsoleted https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options. The new solution is CSP but I see there is already https://github.com/go-gitea/gitea/issues/305 on the topic, and I guess that moving to the new iframe handling should be done as part of it. (Note: Strict-Transport-Security and Referrer-Policy are not to be set by Gitea, this is admin policy and likely configured more globally) Regards. ### Screenshots ![image](https://github.com/user-attachments/assets/85f78ccc-d307-4bc1-877a-47b8d15f6ce0)

GiteaMirror added the type/proposal label 2025-11-02 10:56:53 -06:00

GiteaMirror commented

2025-11-02 10:56:53 -06:00

@wxiaoguang commented on GitHub (Jan 3, 2025):

Some headers like CSP can't be added due to some legacy problems (still need a lot of refactorings): Content-Security-Policy #305

Some options like STS might not satisfy every user, some users do not want it.

At least, you could setup a reverse proxy and add any header you like.

@wxiaoguang commented on GitHub (Jan 3, 2025): Some headers like CSP can't be added due to some legacy problems (still need a lot of refactorings): Content-Security-Policy #305 Some options like STS might not satisfy every user, some users do not want it. ---- At least, you could setup a reverse proxy and add any header you like.

GiteaMirror commented

2025-11-02 10:56:54 -06:00

@wxiaoguang commented on GitHub (Jan 3, 2025):

For "X-Content-Type-Options", Gitea does set this header for these user-generated contents.

While I think it is fine to enable it for all pages, but we need to figure out more details.

@wxiaoguang commented on GitHub (Jan 3, 2025): For "X-Content-Type-Options", Gitea does set this header for these user-generated contents. While I think it is fine to enable it for all pages, but we need to figure out more details. ![image](https://github.com/user-attachments/assets/9c64e0b3-d467-4a50-b140-aa12412cf7e4)

GiteaMirror commented

2025-11-02 10:56:54 -06:00

@ArchangeGabriel commented on GitHub (Jan 3, 2025):

Some headers like CSP can't be added due to some legacy problems (still need a lot of refactorings): Content-Security-Policy #305

Yeah I know, and actually linked that issue in my message. ;)

Some options like STS might not satisfy every user, some users do not want it.

Quoting myself:

(Note: Strict-Transport-Security and Referrer-Policy are not to be set by Gitea, this is admin policy and likely configured more globally)

At least, you could setup a reverse proxy and add any header you like.

That’s actually what I do (using nginx as stated above), but it is not very convenient for two reasons:

If a header is added by me and gitea, it will be present twice, and that is considered as bad practice. So for X-Content-Type-Options, if I had it generally, it will be present twice on those files (currently the case since I ignored that fact, which is actually a good thing but I think it would be safer to just set it everywhere and be done with that).
If I want to work around 1. by only setting the relevant headers for the Gitea part of my nginx configuration, I also have to duplicate every other add_header instruction because nginx ignore any existing more general ones if you define a more specific one. And I have some for STS, for Referrer-Policy, for Expect-CT, for QUIC advertising… Having to set them all again is not very friendly.

@ArchangeGabriel commented on GitHub (Jan 3, 2025): > Some headers like CSP can't be added due to some legacy problems (still need a lot of refactorings): Content-Security-Policy #305 Yeah I know, and actually linked that issue in my message. ;) > Some options like STS might not satisfy every user, some users do not want it. Quoting myself: > (Note: Strict-Transport-Security and Referrer-Policy are not to be set by Gitea, this is admin policy and likely configured more globally) > At least, you could setup a reverse proxy and add any header you like. That’s actually what I do (using nginx as stated above), but it is not very convenient for two reasons: 1. If a header is added by me and gitea, it will be present twice, and that is considered as bad practice. So for `X-Content-Type-Options`, if I had it generally, it will be present twice on those files (currently the case since I ignored that fact, which is actually a good thing but I think it would be safer to just set it everywhere and be done with that). 2. If I want to work around 1. by only setting the relevant headers for the Gitea part of my nginx configuration, I also have to duplicate every other `add_header` instruction because nginx ignore any existing more general ones if you define a more specific one. And I have some for STS, for Referrer-Policy, for Expect-CT, for QUIC advertising… Having to set them all again is not very friendly.

GiteaMirror commented

2025-11-02 10:56:54 -06:00

@wxiaoguang commented on GitHub (Jan 3, 2025):

That’s actually what I do (using nginx as stated above), but it is not very convenient for two reasons:

Yep, agree. Just some thoughts:

If a header is added by me and gitea, it will be present twice

I guess no .... because all reverse proxy could merge duplicate headers. And yes, I agree that if we could have a clear solution in Gitea, it is better.

I also have to duplicate every other add_header instruction because nginx ignore any existing more general ones if you define a more specific one.

Yep, that's a problem, nginx doesn't inherit other headers if a header is set in a section .....

@wxiaoguang commented on GitHub (Jan 3, 2025): > That’s actually what I do (using nginx as stated above), but it is not very convenient for two reasons: Yep, agree. Just some thoughts: > If a header is added by me and gitea, it will be present twice I guess no .... because all reverse proxy could merge duplicate headers. And yes, I agree that if we could have a clear solution in Gitea, it is better. > I also have to duplicate every other add_header instruction because nginx ignore any existing more general ones if you define a more specific one. Yep, that's a problem, nginx doesn't inherit other headers if a header is set in a section .....

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#13907