Description
This has come up several times in the past couple weeks from various agencies looking to comply with HTTPS requirements.
Our current HTTPS situation is:
- For website content, we redirect all requests to HTTPS (eg, http://api.data.gov or http://developer.nrel.gov get redirected to HTTPS).
- HSTS headers are in place for all domains.
- For API requests, the situations is a bit more complicated, but in essence we force HTTPS usage (eg, http://api.commerce.gov/api/blogs?api_key=DEMO_KEY returns an error when accessed over HTTP).
- The short-ish version of this setup is that we don't want to use redirects, since they're often not followed by API clients (and even if they were followed, they usually aren't remembered, so initial requests would continue to be sent insecurely). So instead, we return errors for non-HTTPS usage and require the API user explicitly use the HTTPS version. More details: https://https.cio.gov/apis/#technical-considerations More backstory on our implementation: HTTPS by default #34
So by and large, we already require HTTPS for accessing all of our content, but there is one little exception that's recently come up in Pulse and other agency scans. The issue is in how we handle requests to unknown requests that are neither for website content or API requests. In these situations, our HTTPS redirects for website content don't kick in (since it's not a website request), and since the requests aren't API requests either, the HTTPS-only logic for APIs doesn't kick in. This situation most frequently happens on agency subdomains where there's no website configured and no API setup at the root. So, for example, this "NOT_FOUND" response is available over http: http://api.commerce.gov/
So in order to solve this, we need to also make sure we redirect these "not found" responses to HTTPS. Since these requests aren't to a known API, then redirecting them should be safe (since I don't think we need to explicitly worry about how API clients might respond). This should be pretty straightforward, we just need to be careful about how we go about these redirects so we don't interfere with our existing HTTPS-only logic for API requests.