Account for hosts with/without ports in origin check #6166

Activity

1. code-asher

   added

   bugSomething isn't workingSomething isn't working

   triageThis issue needs to be triaged by a maintainerThis issue needs to be triaged by a maintainer

   on Apr 24, 2023
2. code-asher

   changed the title [-]Account for hosts with 443 and 80 in origin check[/-] [+]Account for hosts with ports in origin check[/+] on Apr 24, 2023
3. code-asher

   added

   needs-decision

   and removed

   triageThis issue needs to be triaged by a maintainerThis issue needs to be triaged by a maintainer

   on Apr 24, 2023
4. code-asher

   changed the title [-]Account for hosts with ports in origin check[/-] [+]Account for hosts with/witohut ports in origin check[/+] on Apr 24, 2023
5. code-asher

   changed the title [-]Account for hosts with/witohut ports in origin check[/-] [+]Account for hosts with/without ports in origin check[/+] on Apr 24, 2023
6. smerschjohann commented on May 10, 2023

   

   smerschjohann

   on May 10, 2023

   Contributor

   More actions

   But I am not sure we should do anything; maybe the correct course of action is to edit the proxy config so the host and origin headers match. I have looked at other software but they all seem to do exact matches without messing around with the port. We could just edit the documentation to use $http_host.

   I just stumbled upon this issue. The X-Forwarded-Host describes the host domain, so it should not contain the port. If you want to give information about the protocol (http, https) there is another header for that: X-Forwarded-Proto. The port itself is typically irrelevant.
7. code-asher commented on May 11, 2023

   

   code-asher

   on May 11, 2023

   MemberAuthor

   More actions

   Oh thanks! Interesting, I never noticed it explicitly excluded the port. Seems odd since Host itself does include the port.

   I believe the attack only occurs across sub-domains and not across ports since browsers would treat the latter as separate origins so with everything considered sounds like we can just ignore the port.
8. code-asher

   removed

   needs-decision

   on Jul 11, 2024
9. code-asher

   marked Fresh copy of code-server 4.98.2 fills the log with Content Security Policy error on Chrome #7285 as a duplicate of this issue on Apr 7, 2026
10. harshbhx commented on Oct 14, 2026

    

    harshbhx

    on Oct 14, 2026

    Contributor

    More actions

    Hi @code-asher! I'd like to work on this, and I have a fix ready to send once my current PR (#8055) is through.

    One thing I wanted to check with you first. While implementing "ignore the port", I realised it would also let in requests from a different port on the same hostname. Browsers keep different ports as separate origins, but cookies aren't scoped by port, so a page on example.com:3000 could open a websocket to code-server and the session cookie would be sent with it. Today the exact match blocks that.

    So I went with a slightly stricter rule that still fixes both setups from the issue:

    • Hostnames must always match.
    • A forwarded host without a port is accepted, which covers nginx's $host.
    • Default ports count as no port, so example.com:443 matches https://example.com.
    • If both sides have a port, they must match, so localhost:8080 vs localhost:8081 is still rejected.

    Origin	Forwarded host	Today	Proposed
    https://example.com	example.com:443	❌	✅
    https://example.com:8080	example.com	❌	✅
    http://localhost:8080	localhost:8081	❌	❌

    Does that sound good to you, or would you rather drop the port comparison entirely? Either way is a small change on my side.
11. smerschjohann commented on Oct 14, 2026

    

    smerschjohann

    on Oct 14, 2026

    Last edited by smerschjohann

    Contributor

    More actions

    I don't understand that table. The only thing that can be extended, if there really is the need is: https://domain.tld -> https://domain.tld:443 and http://domain.tld -> http://doman.tld:80

    Everything else IS NOT the same origin. So your table should never be right.

    just use the default forwarding configs and you won't have a problem, it is not a problem of code-server.

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Port $server_port;