No TLS enforcement, no `Strict-Transport-Security` header

• Context: Cloud
• Category: Interception
• Severity: High

Evidence

The application has no mechanism to enforce HTTPS. The Docker image listens on port 3000 with plain HTTP:

# Dockerfile
EXPOSE 3000
CMD ["pnpm", "start"]

There is no TLS termination configured at the application level. If the container is placed behind a reverse proxy that does not enforce HTTPS, or if accessed directly on an internal network, all traffic — including Bearer tokens in query strings (see C-02), article content sent to OpenAI, and streamed SSE responses — is transmitted in plaintext.

Since next.config.ts contains no Strict-Transport-Security header, browsers will not enforce HTTPS even on subsequent loads.

Attack scenario (MITM): On a corporate network with TLS inspection enabled, the inspection appliance can read all Bearer tokens in URL query strings and all content sent to external AI services, without the application or user being aware.

Affected files: Dockerfile, next.config.ts

Start with Dockerfile and next.config.ts, then trace how the application is exposed and how response headers are configured. Confirm the deployment path enforces HTTPS and that Strict-Transport-Security is delivered, including when the container is accessed through a reverse proxy; verify the resulting configuration with an HTTPS request.