Backend Interview: Why Should an Authenticated HTTP API Avoid Redirecting to HTTPS?

Prompt and scope

Your authenticated API listens on both HTTP and HTTPS, and HTTP requests receive a 301 to HTTPS. Explain the risk, server and client changes, and a migration plan for legacy clients. The prompt is grounded in the HTTPAPI working group’s May 2026 Internet-Draft; it remains work in progress and is not a final RFC.

What the interviewer is testing

• Recognizing that credentials have crossed a plaintext network before a redirect occurs.
• Combining HSTS, HTTPS DNS records, connection blocking, and Secure cookies.
• Handling shared hosts, legacy clients, proxies, and credential revocation.
• Proving risk reduction with measurable signals rather than saying only “use HTTPS.”

Questions to clarify before answering

1. Do HTTP and HTTPS use the same hostname and listener?
2. Are credentials Bearer tokens, cookies, API keys, or request signatures?
3. Are there legacy clients, enterprise proxies, or internal callers that cannot upgrade immediately?
4. Does the HTTP entry point also serve unauthenticated resources?
5. Do you already use HSTS, HTTPS DNS records, key rotation, and audit logs?

30-second answer framework

A redirect cannot recover credentials already sent in plaintext; a passive observer may copy a Bearer token or cookie. Prefer making the HTTP entry fail before an authenticated connection, use HTTPS DNS records and HSTS to reduce first-use and repeat misconfiguration, set Secure on cookies, and have clients reject insecure URLs by default. If immediate blocking is impossible, return the same 403 for every credential-bearing plaintext request and revoke credentials that may have leaked. Migrate with metrics, a gray period, and rollback.

Step-by-step deep dive

1. Explain when the leak happens

The client sends an HTTP request first, potentially containing Authorization, a cookie, or an API key. A later 301 cannot erase what crossed the network. An attacker can replay a Bearer token or cookie. A successful HTTPS retry can also hide a client misconfiguration for a long time.

2. Design the server entry point

For authenticated endpoints, first disable public plaintext listening or restrict port 80 to an explicitly trusted network. Do not treat a 301 as a security control. If a shared host must keep HTTP, the gateway should recognize credential-bearing requests and return the same 403 without revealing whether a credential is valid.

HTTP/1.1 403 Forbidden
Cache-Control: no-store
Content-Length: 0

The response must not differ for valid and invalid credentials, or an attacker gains a test oracle for stolen values.

3. Reduce first-use client mistakes

HTTPS DNS records can tell a client to use a secure connection during connection setup. HSTS upgrades later connections after a successful HTTPS visit. Neither is perfect: HSTS depends on that prior connection and client persistence, while DNS records can be blocked. SDKs, CLIs, and configuration validation should reject http by default and provide an actionable remediation message.

4. Restrict credential use

Cookies should carry the Secure attribute. Tokens should be limited to secure contexts, with request- or connection-bound signatures where appropriate. Revocation differs by credential type: replayable API keys, Bearer tokens, and cookies generally need immediate revocation, while a non-forgeable derived signature may not.

5. Handle exposed credentials

Treat any credential received over plaintext as potentially compromised. The server can return a uniform 403 first, then explain “credential revoked” on the next secure use. Record the revocation in an audit log, notify the owner to rotate it, and never place sensitive values in logs, caches, or error bodies.

6. Migrate safely

Reject HTTP first in SDKs and test environments, then disable the plaintext entry point for new tenants, and finally migrate legacy tenants in batches. Give clients that require an old proxy a short transition endpoint that never accepts credentials. Set a deadline, monitor 403 rates and rotation completion, and move authenticated APIs to a separate hostname or gateway policy when public resources still need HTTP.

7. Verify the controls

Use packet capture to confirm that Authorization, cookies, and API keys never appear on plaintext. Verify connection failure and 403 behavior, then test HSTS caching, first visit, proxies, retries, and rollback. Track plaintext requests, credential-bearing plaintext requests, automatic revocations, 403 false positives, legacy-client share, and migration completion.

High-quality sample answer

I would not treat a 301 as the security solution for an authenticated API, because the credential has already crossed a plaintext network before the redirect. A passive observer can copy a Bearer token or cookie, and a successful HTTPS retry can hide the client’s mistake.

The server should first disable public HTTP on authenticated endpoints. If a shared host cannot do that immediately, the gateway returns the same 403 for every credential-bearing HTTP request, does not reveal credential validity, and marks the credential as potentially exposed. Replayable tokens, API keys, and cookies are revoked and rotated. SDKs, CLIs, and configuration checks reject http by default; HTTPS DNS records and HSTS reduce first-use and repeat mistakes, and cookies carry Secure.

Migrate in stages across test environments, new tenants, and legacy tenants. Give enterprise proxies a short transition path that accepts no credentials. Verify with packet captures and measure plaintext requests, credential-bearing plaintext requests, revocation and rotation completion, 403 false positives, and legacy-client share. The IETF document is still a draft, so deployment commitments remain adjustable.

Common mistakes

• Assuming an HTTPS redirect protects an Authorization header or cookie already sent.
• Configuring only HSTS while ignoring first use, legacy clients, and non-browser SDKs.
• Returning different plaintext responses for valid and invalid credentials.
• Treating every credential as identical and ignoring derived signatures versus replayable tokens.
• Removing HTTP without a migration, monitoring, revocation, or rollback plan.

Follow-up questions and responses

What if the HTTP entry point still serves public resources?

Move the authenticated API to a separate hostname, or isolate paths and credential headers at the gateway. Public resources can have their own redirect policy; authenticated endpoints must reject credential-bearing plaintext requests.

Does HSTS solve the first visit?

Not completely. HSTS needs a successful HTTPS connection and client persistence. SDKs, configuration checks, HTTPS DNS records, and deployment checks must cover first connection as well.

When should credentials be revoked?

Treat credentials seen in plaintext as potentially exposed. Revoke and rotate replayable tokens, API keys, and cookies. For a non-forgeable derived signature, decide from the threat model whether revocation is necessary.

How do you avoid a disruptive migration?

Enable rejection in tests and new tenants first, observe legacy clients and 403 false positives, then migrate in batches. Keep a short transition endpoint that accepts no credentials and remove it after a clear deadline.