Proposal : Permit modification of X-FRAME-OPTIONS headers #3829

New Issue

GiteaMirror · 2025-11-02T05:27:13-06:00

GiteaMirror commented

2025-11-02 05:27:13 -06:00

Originally created by @Noctisae on GitHub (Aug 23, 2019).

Hello,

I'd like to file a proposal concerning the HTTP headers sent by Gitea, due to a specific user case I'm running into.

Currently, Gitea always send the HTTP header "X-FRAME-OPTIONS" with the value "SAMEORIGIN" in all requests, which is a good security practice. However, I'm currently running into a case where I need to set this header to a value like "ALLOW-FROM <external_site>", to permit framing Gitea inside a portal I'm currently working on. Because I do not have control over the proxy serving Gitea, one of the solution I have is to set the header from Gitea directly. I could also mount a proxy on the same machine as Gitea to have this proxy serve the right headers instead of Gitea, but (in my view) this solution is a complicated workaround of a otherwise easy to fix issue.

I'm proposing to permit the configuration of this specific header with a line inside the app.ini, with a default value of SAMEORIGIN (to ensure the default behavior of Gitea isn't modified with the proposed change). This way, anyone could set the value of this header to the value which suits their need, without compromising the default security of the solution. I do understand my case is uncommon, but I think this evolution could be implemented very easily (due to the fact that I've already done it on my part). I can propose the PR if interested.

Thoughts?

Originally created by @Noctisae on GitHub (Aug 23, 2019). Hello, I'd like to file a proposal concerning the HTTP headers sent by Gitea, due to a specific user case I'm running into. Currently, Gitea always send the HTTP header "X-FRAME-OPTIONS" with the value "SAMEORIGIN" in all requests, which is a good security practice. However, I'm currently running into a case where I need to set this header to a value like "ALLOW-FROM <external_site>", to permit framing Gitea inside a portal I'm currently working on. Because I do not have control over the proxy serving Gitea, one of the solution I have is to set the header from Gitea directly. I could also mount a proxy on the same machine as Gitea to have this proxy serve the right headers instead of Gitea, but (in my view) this solution is a complicated workaround of a otherwise easy to fix issue. I'm proposing to permit the configuration of this specific header with a line inside the app.ini, with a default value of SAMEORIGIN (to ensure the default behavior of Gitea isn't modified with the proposed change). This way, anyone could set the value of this header to the value which suits their need, without compromising the default security of the solution. I do understand my case is uncommon, but I think this evolution could be implemented very easily (due to the fact that I've already done it on my part). I can propose the PR if interested. Thoughts?

GiteaMirror added the type/proposal label 2025-11-02 05:27:13 -06:00

GiteaMirror closed this issue

2025-11-02 05:27:13 -06:00

GiteaMirror commented

2025-11-02 05:27:14 -06:00

@STaRDoGG commented on GitHub (Sep 5, 2019):

I'd like to be able to individually control the sameorigin header as well; perhaps per repo?

My use case:

I'm running Gitea locally via docker on a LAN machine.
I also own a public website, and in a post on it, I want to iframe the raw code of one repo (in this case just a single file in the repo; a .css file) on the local Gitea machine. This way, if/when I ever update the source code locally it'll always fetch the latest version of that code within the iframe of that post.

Currently I can't due to the sameorigin header. If I could disable that header for that specific file or repo, then I'd be able to accomplish this.

@STaRDoGG commented on GitHub (Sep 5, 2019): I'd like to be able to individually control the `sameorigin` header as well; perhaps per repo? My use case: - I'm running Gitea locally via docker on a LAN machine. - I also own a public website, and in a post on it, I want to iframe the raw code of one repo (in this case just a single file in the repo; a .css file) on the local Gitea machine. This way, if/when I ever update the source code locally it'll always fetch the latest version of that code within the iframe of that post. Currently I can't due to the `sameorigin` header. If I could disable that header for that specific file or repo, then I'd be able to accomplish this.

GiteaMirror commented

2025-11-02 05:27:14 -06:00

@jap1968 commented on GitHub (May 29, 2020):

Same problem here. I am running gitea and swagger editor in two different containers. I would like to load a .yaml file from gitea into the editor. Swagger complains about CORS blocking the request, but maybe the real problem is the X-FRAME-OPTIONS header.

@jap1968 commented on GitHub (May 29, 2020): Same problem here. I am running gitea and swagger editor in two different containers. I would like to load a .yaml file from gitea into the editor. Swagger complains about CORS blocking the request, but maybe the real problem is the X-FRAME-OPTIONS header.

GiteaMirror commented

2025-11-02 05:27:14 -06:00

@lafriks commented on GitHub (May 29, 2020):

CORS has different headers that need to be added to allow cross origin requests

@lafriks commented on GitHub (May 29, 2020): CORS has different headers that need to be added to allow cross origin requests

GiteaMirror commented

2025-11-02 05:27:15 -06:00

@spasche commented on GitHub (Jul 25, 2021):

I agree that having a way to control X-Frame-Options header at the application level would be useful.

If you use nginx as a reverse proxy, it's possible to override it there (credits to https://serverfault.com/a/982013):

server {
    server_name gitea.example.com;
    [...]
    location / {
        proxy_pass http://gitea:8080;

        proxy_hide_header X-Frame-Options;
        add_header X-Frame-Options "allow-from https://trusted.example.com/" always;
    }
}

@spasche commented on GitHub (Jul 25, 2021): I agree that having a way to control `X-Frame-Options` header at the application level would be useful. If you use nginx as a reverse proxy, it's possible to override it there (credits to https://serverfault.com/a/982013): ``` server { server_name gitea.example.com; [...] location / { proxy_pass http://gitea:8080; proxy_hide_header X-Frame-Options; add_header X-Frame-Options "allow-from https://trusted.example.com/" always; } } ```

GiteaMirror referenced this issue

2025-11-02 15:41:27 -06:00

[PR #5383] [MERGED] API: '/orgs/:org/repos': return private repos with read access #17775

GiteaMirror referenced this issue

2025-11-02 15:44:19 -06:00

[PR #5393] [MERGED] API: '/orgs/:org/repos': return private repos with read access #17780

Sign in to join this conversation.