Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

API Shouldn't Redirect HTTP to HTTPS

jviide.iki.fi

Post reply on HN
Print view View original

151–160 of 310 posts

Re: API Shouldn't Redirect HTTP to HTTPS

#151

Post by ants_everywhere »

marcosdumay wrote: post #147
athyuttamre wrote: post #105

Great article! We've updated the OpenAI API to 403 on HTTP requests instead of redirecting. $ curl http://api.openai.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 123" \ -d '{}' { "error": { "type": "invalid_request_error", "code": "http_unsupported", "message": "The OpenAI API is only accessible over HTTPS. Ensure the URL starts with 'https://' and not 'http://'.", "param"…

If anybody is looking to copy in a public API, please return 400 and don't misuse a standard code.

400 is usually for a malformed request. It seems like in this case the request is well formed, it's just not allowed. 403 seems reasonable if the user isn't authorized to make a request to the URL, which they aren't. Some APIs return redirects which also seems pretty reasonable.

Re: API Shouldn't Redirect HTTP to HTTPS

#152

Post by NotYourLawyer »

from-nibly wrote: post #141
athyuttamre wrote: post #105

Great article! We've updated the OpenAI API to 403 on HTTP requests instead of redirecting. $ curl http://api.openai.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 123" \ -d '{}' { "error": { "type": "invalid_request_error", "code": "http_unsupported", "message": "The OpenAI API is only accessible over HTTPS. Ensure the URL starts with 'https://' and not 'http://'.", "param"…

This is better as it allow you to immediately notice that there's an issue. However it still facilitates api key exposing on the initial request.

How would the endpoint prevent that?

Re: API Shouldn't Redirect HTTP to HTTPS

#153

Post by amscanne »

lofenfew wrote: post #142
Eduard wrote: post #134

Earlier quoted context omitted.

that's more secure, but still not bulletproof: A MITM (e.g. a router along a multi-hop route between the victim client and StackExchange) could silently drop the unsafe HTTP requests and maliciously repackage it as an HTTPS request, thereby circumventing the revocation. Also: even if an insecure HTTP request isn't dropped / makes it through to StackExchange's endpoint eventually (and thereby triggering the API key re…

There's absolutely nothing you can do to prevent an active MITM attack over HTTP

Have the authentication header effectively be a signed hash of relevant headers and the full URL, rather than a simple bearer token?

Re: API Shouldn't Redirect HTTP to HTTPS

#154

Post by Hizonner »

athyuttamre wrote: post #105

Great article! We've updated the OpenAI API to 403 on HTTP requests instead of redirecting. $ curl http://api.openai.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 123" \ -d '{}' { "error": { "type": "invalid_request_error", "code": "http_unsupported", "message": "The OpenAI API is only accessible over HTTPS. Ensure the URL starts with 'https://' and not 'http://'.", "param"…

Why not just stop listening on port 80, period?

Re: API Shouldn't Redirect HTTP to HTTPS

#155

Post by endofreach »

ants_everywhere wrote: post #151
marcosdumay wrote: post #147

Earlier quoted context omitted.

If anybody is looking to copy in a public API, please return 400 and don't misuse a standard code.

400 is usually for a malformed request. It seems like in this case the request is well formed, it's just not allowed. 403 seems reasonable if the user isn't authorized to make a request to the URL, which they aren't. Some APIs return redirects which also seems pretty reasonable.

Well in that case really anything is a 403.

Re: API Shouldn't Redirect HTTP to HTTPS

#156

Post by kijin »

ants_everywhere wrote: post #151
marcosdumay wrote: post #147

Earlier quoted context omitted.

If anybody is looking to copy in a public API, please return 400 and don't misuse a standard code.

400 is usually for a malformed request. It seems like in this case the request is well formed, it's just not allowed. 403 seems reasonable if the user isn't authorized to make a request to the URL, which they aren't. Some APIs return redirects which also seems pretty reasonable.

404 would also work, since the resource does not exist at the http: address.

Re: API Shouldn't Redirect HTTP to HTTPS

#157

Post by Pesthuf »

Hizonner wrote: post #154
athyuttamre wrote: post #105

Great article! We've updated the OpenAI API to 403 on HTTP requests instead of redirecting. $ curl http://api.openai.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 123" \ -d '{}' { "error": { "type": "invalid_request_error", "code": "http_unsupported", "message": "The OpenAI API is only accessible over HTTPS. Ensure the URL starts with 'https://' and not 'http://'.", "param"…

Why not just stop listening on port 80, period?

It’s a good option, but you can’t give users a reason for the failure. They might even assume your service is broken.

Re: API Shouldn't Redirect HTTP to HTTPS

#158

Post by chrismorgan »

npm is misusing 426 Upgrade Required.

https://httpwg.org/specs/rfc9110.html#status.426:

> The server MUST send an Upgrade header field in a 426 response to indicate the required protocol(s) (Section 7.8).

https://httpwg.org/specs/rfc9110.html#field.upgrade:

> The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch the underlying connection (transport) protocol, nor to switch the existing communication to a different connection. For those purposes, it is more appropriate to use a 3xx (Redirection) response (Section 15.4).

If you’re going to talk cleartext HTTP and issue a client error rather than redirecting, 403 Forbidden or 410 Gone are the two most clearly correct codes to use.

Ignoring the mandated semantics and requirements of status codes is sadly not as rare as it should be. A few I’ve encountered more than once or twice: 401 Unauthorized without using WWW-Authenticate and Authorization; 405 Method Not Allowed without providing Allow; 412 Precondition Failed for business logic preconditions rather than HTTP preconditions; 417 Expectation Failed for something other than an Expect header. I think it only ever really happens with 4xx client errors.

Re: API Shouldn't Redirect HTTP to HTTPS

#159

Post by TheDong »

NotYourLawyer wrote: post #152
from-nibly wrote: post #141

Earlier quoted context omitted.

This is better as it allow you to immediately notice that there's an issue. However it still facilitates api key exposing on the initial request.

How would the endpoint prevent that?

Not listening on port 80, such that the user gets a connection refused, would result in the client not sending the api key over the wire at all.

I personally think listening, accepting that user mistakes can expose API keys to MITMs, and returning the user-facing error is better than a "connection refused" error, but it is a tradeoff.

Post reply on HN