Security teams should treat HTTP as unacceptable whenever a site transmits credentials, payment details, personal data, or any session data that could be exposed on the network. HTTP sends information in clear text, so anyone who can observe traffic can read it. The practical rule is simple: if users authenticate, submit forms, or exchange sensitive data, HTTPS should be mandatory.
When HTTP Stops Being Acceptable for a Public Website
For a public site, HTTP is only defensible when the traffic is truly low stakes, such as static content with no login, no form submission, and no data collection beyond what a browser can fetch without exposing users. The moment the site accepts credentials, personal data, payment details, or session-bearing interactions, plaintext transport becomes a security liability rather than a convenience.
What Actually Changes the Decision
The decision is not about whether a page “looks sensitive” but whether the transport can expose something useful to an observer on the network. A single login form, newsletter signup, contact form, or account session is enough to move the site into HTTPS territory because an attacker only needs one clear-text exchange to capture data or hijack a session.
That means teams should judge HTTP by data flow, not by brand, size, or traffic volume. If the page creates authentication state, carries cookies, or transmits any information that would be harmful if read in transit, HTTP is no longer an acceptable default. For a public website, the practical threshold is usually much lower than teams expect because many “simple” pages still handle user input or session state.
How to Apply the Rule in Practice
A useful way to operationalise the decision is to map each public endpoint into one of three buckets: static, interactive, or sensitive. Static pages can sometimes remain plain HTTP during limited transitional scenarios, but interactive and sensitive pages should be treated as HTTPS-only. Once one part of a site needs HTTPS, the safer operational choice is usually to move the whole public surface to HTTPS and avoid mixed trust assumptions.
- Require HTTPS for any page that authenticates a user.
- Require HTTPS for any form that submits personal, financial, or account data.
- Require HTTPS for any page that sets, reads, or depends on session cookies.
- Redirect HTTP to HTTPS and remove legacy clear-text entry points rather than keeping both live.
Risk and Threat Considerations
HTTP exposes data to passive interception and active manipulation. On a public website that means credentials, session tokens, and submitted data can be stolen or altered by anyone able to observe traffic, including on hostile Wi-Fi, compromised routers, or intermediary networks.
Failure mechanism: Clear-text transport lets an attacker read or modify requests and responses, then reuse captured credentials or session material to impersonate the user.
Impact: Account takeover, data disclosure, transaction tampering, and user trust loss can all follow from a single unsafe HTTP interaction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | Protects public web traffic from clear-text exposure and tampering. |
| IA-5 — Authenticator Management | HTTP becomes unacceptable when credentials or session material could be exposed in transit. | |
| Recommendation — Enforce encrypted transport for user sessions and submitted data. Protect and rotate authenticators so they are never sent over clear text. | ||
| OWASP ASVS | V12 — Secure Communication | Directly addresses transport security for web applications and public sites. |
| Recommendation — Require HTTPS for pages that handle login, forms, or session state. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Supports encrypted communication where data confidentiality in transit is needed. |
| Recommendation — Apply cryptographic protection to public web traffic carrying sensitive data. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Supports protecting sensitive web data from exposure during transmission. |
| Recommendation — Use encrypted transport wherever public traffic can carry sensitive information. | ||
Practitioner Guidance
What to verify: Confirm whether any HTTP endpoint can reach authentication, cookies, form submissions, or redirects that preserve user state. If yes, the site should be treated as HTTPS-required, even if the visible page seems informational.
Decision rule: If the public site handles anything a user would not want exposed to a network observer, do not leave HTTP as a supported path. Keep HTTP only when you are comfortable with every byte being visible and alterable in transit.
Practitioner takeaway: The safest rule is to default to HTTPS for the entire public site once any meaningful interaction exists, because partial exceptions create the exact clear-text paths attackers look for.
Related resources from NHI Mgmt Group
- How should security teams decide between WinRM over HTTP and HTTPS?
- How should security teams decide when representative data classification is acceptable?
- How do security teams decide whether a self-service lifecycle flow is acceptable?
- How should security teams decide whether a trust service is acceptable for EU business?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
