[athyuttamre]

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": null
    }
  }

[bhawks]

You may want to disable path resolution as well.

http://api.openai.com/v1/chat/completions/../bar responds with error messages about http://api.openai.com/v1/chat/bar which might suggest some path traversal vulnerability that could be exploited.

Generally an API client is not going to need .. to be resolved in a path. It should return 400 - Bad Request (deceptive routing).

[alberth]

Doesn’t returning a 403 on HTTP break HSTS?

https://security.stackexchange.com/questions/122441/should-h...

Doesn’t HSTS require only responding to a user via HTTPS (even for error codes).

[kji]

HSTS is intended for browsers. For API clients the correct behavior (following curl's lead) is probably to never follow/make any redirects by default.

[LinAGKar]

The HSTS header is only effective when it's received over HTTPS. And if it has taken effect, the client won't try to access HTTP anymore, so it won't even know what response it would have gotten from HTTP.

[josephcsible]

What about this then? When the request is made over insecure HTTP, revoke the API key used, but then send the usual redirect response for HSTS. Then, when/if the request gets repeated over HTTPS, notice the key is revoked and so respond to that one with 403.

[gerdesj]

HSTS is a note to the browser to insist on TLS when hitting a website. It is sent as a header, with a timescale, regardless of http/https.

[Hizonner]

Why not just stop listening on port 80, period?

[Pesthuf]

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

[freedomben]

I've done that myself and have consumed many others who have done it, and I don't think it's better. Much better to get a response that tells you to use https for the API. (for browser also a redirect is a must for UX, though our context here is API)

[ikiris]

Because the whole point is a mitm can compromise it, and the mitm can listen on 80 regardless if you turn yours off.

[freedomben]

Thank you for sharing! I think this sort of thing is what makes HN great.

Have you rolled this out to prod yet? Did you check how many users this might effect? I can imagine some (probably amateur) apps are going to break when this hits, so some notice might be nice.

I'm not asking those questions critically, mainly wanting to facilitate a full discussion around the pros and cons (I think the pros are are much stronger personally).

[from-nibly]

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.

[NotYourLawyer]

How would the endpoint prevent that?

[marcosdumay]

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

[hn_throwaway_99]

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)

[ants_everywhere]

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.

[CGamesPlay]

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.