API key

HTTP APIs API keys for HTTP-based APIs can be sent in multiple ways: The access token is often a JSON Web Token (JWT) in the HTTP Authorization header: POST /something HTTP/1.1 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... In the query string: POST /something?api_key=abcdef12345 HTTP/1.1 As a request header: GET /something HTTP/1.1 X-API-Key: abcdef12345 As a cookie: GET /something HTTP/1.1 Cookie: X-API-KEY=abcdef12345 == Security ==

API keys are generally not considered secure; they are typically accessible to clients, making it easy for someone to steal an API key. Keys often have no expiration, meaning a stolen key can be used indefinitely unless revoked or regenerated. Keys are supposed to be a secret known only by the client and server, so they should not be communicated over an insecure channel and can only be considered secure when used in conjunction with other security mechanisms such as HTTPS. There are several risk scenarios when using API keys: • Developers may write scripts that contain keys in plaintext. • Developers may hard-code keys into source code, and forget that when they release the code. • Having unprotected keys in mobile apps is dangerous. These risks generally stem from the key being in plaintext, which is potentially accessible to adversaries. == Incidents ==

In 2017, Fallible, a Delaware-based security firm examined 16,000 Android apps and identified over 300 which contained hard-coded API keys for services like Dropbox, Twitter, and Slack. == References ==