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

171–180 of 310 posts

Re: API Shouldn't Redirect HTTP to HTTPS

#171

Post by loa_in_ »

xyst wrote: post #148

Revoking an API key upon a single http request assumes you have a competent team. Have worked with people that have committed sensitive credentials into public repositories, used PRODUCTION secrets for testing, and of course sharing secrets in plain text over IM and group chats. The number of times I have had to deal with password or secret key resets because of this is way too high. I remember working with a guy tha…

It assumes nothing like that. It provides you and your team with a safe opportunity to learn and grow.

Revoking a key like this is a problem that's solution is at worst a dozen clicks away fix. The alternative, leaking keys can be much worse.

So go and reset those creds for the guy who made a mistake happily and be grateful. He had an opportunity to learn.

Re: API Shouldn't Redirect HTTP to HTTPS

#172

Post by inopinatus »

Pesthuf wrote: post #157
Hizonner wrote: post #154

Earlier quoted context omitted.

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.

I think it's fair to assume j. random user isn't typing "http://api.example.net" into their web browser.

leading www perhaps, leading api no.

Re: API Shouldn't Redirect HTTP to HTTPS

#174

Post by throw__away7391 »

Titan2189 wrote: post #138
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…

I'd argue your reasoning is incorrect. By the time your service is developed you would have already changed it to https, as during development every time you tried your API keys sent via http got disabled. So an in-the-wild MITM would never get to see your http request

That's a very good point, I agree. You're always going to run a service at least once.

Re: API Shouldn't Redirect HTTP to HTTPS

#175

Post by hn_throwaway_99 »

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.

Why do you think 403 is the wrong error code? Based on the spec it seems entirely appropriate to me:

> HTTP 403 provides a distinct error case from HTTP 401; while HTTP 401 is returned when the client has not authenticated, and implies that a successful response may be returned following valid authentication, HTTP 403 is returned when the client is not permitted access to the resource despite providing authentication such as insufficient permissions of the authenticated account.[a]

> Error 403: "The server understood the request, but is refusing to authorize it." (RFC 7231)

Re: API Shouldn't Redirect HTTP to HTTPS

#176

Post by CGamesPlay »

makeitdouble wrote: post #169
zepton wrote: post #54

The Stack Exchange API used to revoke API keys sent over HTTP (and return an error message), which is my favorite way to handle this.

Wouldn't this open the door to revoking random API keys sent maliciously ?

This is just a run-of-the-mill DoS attack, with the astronomically unlikely jackpot of additionally invaliding a random unknown user's API key when you get a hit.

Re: API Shouldn't Redirect HTTP to HTTPS

#177

Post by bruce511 »

Townley wrote: post #170
makeitdouble wrote: post #169

Earlier quoted context omitted.

Wouldn't this open the door to revoking random API keys sent maliciously ?

If a malicious party has access to the API key, it should be revoked regardless

Of course. But I think the poster above was referring to just posting random keys to the server.

In other words I don't have your key, or any key, but I have "all of them".

The correct response to this though is that "there are lots of keys, and valid keys are sparse."

In other words the jumper of valid keys that could be invalidated in this way is massively smaller than the list of invalid keys. Think trillions of trillions to 1.

Re: API Shouldn't Redirect HTTP to HTTPS

#179

Post by CGamesPlay »

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.

Not sure how I feel about this (extremely arbitrary) distinction. 400 Bad Request maybe implies that no matter how many times you retry the request, it will never succeed. 403 Forbidden maybe implies that some external change in the authentication system could perhaps allow the same request to succeed in the future? So I guess in that lens I can see the logic, but again, seems extremely arbitrary.

Re: API Shouldn't Redirect HTTP to HTTPS

#180

Post by bruce511 »

kijin wrote: post #156
ants_everywhere wrote: post #151

Earlier quoted context omitted.

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.

True, but 404 has trained us to look hard at the URL part, not the protocol part.

Whereas 403 or 400 are less likely to have so automated built-in handling on the client side.

Post reply on HN