For public facing applications, it may be appropriate to have the web server listening for unencrypted HTTP connections on port 80, and then immediately redirecting them with a permanent redirect (HTTP 301) in order to provide a better experience to users who manually type in the domain name. This should then be supported with the HTTP Strict Transport Security (HSTS) header to prevent them accessing the site over HTTP in the future.
The applies to end user facing parts of applications, but may not necessarily apply to APIs that are often consumed programmatically.
Programmatic HTTP clients like Node.JS's fetch) don't tend to keep browser-like state of things like HSTS headers or permanent redirects that they have seen. Moreover, programmatic HTTP clients often follow redirects by default, so when developer makes an error and uses an http:// URL for an API instead of https://, the error gets masked as everything seems to work normally. As long as the error goes unnoticed the API client sends each request - and potentially sensitive content like API keys - over unencrypted HTTP vulnerable to passive sniffing.
It might therefore make sense to amend the section to recommend either disabling the HTTP interface altogether for API-only endpoints as recommended in the slideset "Common API Security Pitfalls" (see slide 8). When that is not possible, API endpoints could to fail unencrypted requests with e.g. HTTP status code 403 and a descriptive error message instead of redirecting them. This would allow unintended use of unencrypted HTTP to be more easily noticed early during development.
I did a quick and informal survey of APIs offered by popular services listed from the top of my head, and it seems that APIs doing HTTP-to-HTTPS redirects are widespread. An explicit mention in a popular source like this cheatsheet might help there.
How should this be resolved?
A paragraph could be added along these lines:
API-only endpoints should disable HTTP altogether and only support encrypted connections. When that is not possible, API endpoints should fail requests made over unencrypted HTTP connections instead of redirecting them.
What is missing or needs to be updated?
The section Use TLS For All Pages states:
The applies to end user facing parts of applications, but may not necessarily apply to APIs that are often consumed programmatically.
Programmatic HTTP clients like Node.JS's fetch) don't tend to keep browser-like state of things like HSTS headers or permanent redirects that they have seen. Moreover, programmatic HTTP clients often follow redirects by default, so when developer makes an error and uses an
http://URL for an API instead ofhttps://, the error gets masked as everything seems to work normally. As long as the error goes unnoticed the API client sends each request - and potentially sensitive content like API keys - over unencrypted HTTP vulnerable to passive sniffing.It might therefore make sense to amend the section to recommend either disabling the HTTP interface altogether for API-only endpoints as recommended in the slideset "Common API Security Pitfalls" (see slide 8). When that is not possible, API endpoints could to fail unencrypted requests with e.g. HTTP status code 403 and a descriptive error message instead of redirecting them. This would allow unintended use of unencrypted HTTP to be more easily noticed early during development.
I did a quick and informal survey of APIs offered by popular services listed from the top of my head, and it seems that APIs doing HTTP-to-HTTPS redirects are widespread. An explicit mention in a popular source like this cheatsheet might help there.
How should this be resolved?
A paragraph could be added along these lines:
Pull request #1408 suggests this addition.