Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Secure; Flag should be ignored when sending to 'localhost' #382

Open
ertl opened this issue Mar 15, 2024 · 3 comments
Open

Secure; Flag should be ignored when sending to 'localhost' #382

ertl opened this issue Mar 15, 2024 · 3 comments
Projects

Comments

@ertl
Copy link

ertl commented Mar 15, 2024

According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies it is fine to send cookies via http even when the flag secure is set, as long as the receiving host is localhost.

Despite this, a previous attempt to address this problem through pull request #281 was made and subsequently closed. We need to reassess the decision to close the pull request and carefully consider the security implications of allowing cookies to be sent via HTTP in this scenario.

@colincasey
Copy link
Contributor

To be clear, the contributor of #281 self-closed their own pull request. No formal decision was made by the maintainers of this project regarding the validity of that PR 😅

While nothing in RFC6265 explicitly states that there should be an exception for localhost and the Secure attribute, there is some text around secure channels in section 4.1.2.5

The Secure attribute limits the scope of the cookie to "secure" channels (where "secure" is defined by the user agent)

This is an area where I think tough-cookie would benefit from having a better internal representation of a User Agent or User Agent Policy to assist in either determining or configuring how the library behaves in cases like this.

Can you give some more details around your use case @ertl?

@ertl
Copy link
Author

ertl commented Mar 18, 2024

@colincasey Thank you for your response and for clarifying the status of the previous pull request.

You're right to point out that RFC6265 doesn't explicitly mention any exceptions for localhost and the Secure attribute. However, the text around secure channels in section 4.1.2.5 does leave room for interpretation regarding what constitutes a "secure" channel.

Our scenario includes an additional proxy app running on localhost. We believe that accessing the proxy via HTTPS is not practical because the connection through localhost is inherently secure due to its local nature, which limits external access and reduces the risk of interception or tampering.

@colincasey
Copy link
Contributor

@ertl that makes sense. We'd be open to a PR here if that's something you wanted to attempt. Otherwise, this will go in our list of v6 project goals.

@colincasey colincasey added this to Needs triage in v6 via automation Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
v6
Needs triage
Development

No branches or pull requests

2 participants