API Shouldn't Redirect HTTP to HTTPS (jviide.iki.fi)

Article summary

The article argues that APIs should not redirect HTTP requests to HTTPS, as this can mask errors and potentially expose sensitive information, such as API keys. Instead, APIs should either disable their HTTP interface or return a clear error response. The author found that many well-known APIs redirect HTTP requests to HTTPS, which can lead to security issues. The article suggests that APIs should fail fast and visibly when encountering unencrypted requests.

Main themes

• API security
• HTTP to HTTPS redirects
• Encryption and privacy
• Error handling
• Security best practices

What commenters say

• Node.js's built-in fetch should not quietly follow HTTP-to-HTTPS redirects without storing state or notifying the developer.
• HSTS is not relevant for non-stateful clients like fetch, and implementing HSTS checking would add unnecessary complexity.
• Providing APIs over both HTTP and HTTPS can be useful for non-enterprise use cases, but it also exposes sensitive information to potential eavesdroppers.
• HTTPS hides not only the request body but also the URL, making it a better choice for private or sensitive data, although it does not hide the domain name due to SNI.
• Defaulting to HTTPS is better than allowing HTTP requests, even for non-commercial or institutional services, as it provides an additional layer of security and privacy.
• There are trade-offs between using HTTP and HTTPS, and HTTP has its place in certain scenarios, such as when ease of setup and decentralization are more important than security.
• Encrypting all traffic is essential for basic human freedom and privacy, regardless of the threat model or use case.
• Relying solely on HTTPS and CA TLS can create a single point of failure and make it easier for nation-states to intercept traffic.