HSTS
securityFull Name: HTTP Strict Transport Security
Definition
HTTP Strict Transport Security (HSTS) is a web security policy mechanism defined in RFC 6797 that allows web servers to declare that browsers should only interact with them using secure HTTPS connections, never through the insecure HTTP protocol. When a server sends an HSTS header, the browser remembers this policy and automatically converts any future HTTP requests to HTTPS, even if the user types "http://" or clicks an HTTP link. This eliminates the window of vulnerability during the initial HTTP request that attackers could exploit through man-in-the-middle attacks, protocol downgrade attacks, or cookie hijacking. For EUDI Wallet web services -- including credential management portals, issuer discovery endpoints, and relying party registration systems -- HSTS is a mandatory security baseline.
The HSTS Security Header Explained
The HSTS header is deceptively simple but provides powerful protection. A typical HSTS header for an EUDI Wallet service looks like:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
- •max-age=31536000: The browser remembers this policy for one year (31,536,000 seconds). During this period, all requests to this domain are automatically upgraded to HTTPS.
- •includeSubDomains: The policy applies to all subdomains. If the EUDI service uses api.wallet.eudi.eu, cdn.wallet.eudi.eu, etc., all are covered.
- •preload: Signals that the domain should be included in browser HSTS preload lists, protecting even first-time visitors.
HSTS in the EUDI Web Service Security Stack
HSTS is one component of a complete web security header strategy for EUDI Wallet services. Together with other security headers, it creates multiple layers of transport and application security:
HSTS ensures encrypted transport. Content Security Policy (CSP) prevents cross-site scripting and injection attacks. X-Content-Type-Options prevents MIME type sniffing. X-Frame-Options prevents clickjacking. Referrer-Policy controls information leakage through referrer headers. Permissions-Policy restricts access to browser APIs. Together, these headers implement defense in depth at the HTTP layer.
For EUDI Wallet API endpoints (OpenID4VCI, OpenID4VP), HSTS works alongside TLS 1.3 with certificate pinning to ensure wallet-to-server communication cannot be intercepted or downgraded. The wallet app enforces HTTPS for all API communication, but HSTS provides additional protection for web-based interaction points like the issuer discovery portal and the wallet management dashboard.
Implementation Considerations for EUDI Operators
Implementing HSTS requires careful planning to avoid service disruption:
Gradual rollout: Start with a short max-age (e.g., 300 seconds / 5 minutes) to test that all resources load correctly over HTTPS. Gradually increase to the full one-year duration. Once includeSubDomains is enabled, every subdomain must have valid HTTPS certificates or users will be unable to access them.
Certificate management: HSTS makes certificate failures more severe because the browser refuses to show the "proceed anyway" option for HSTS-enabled sites. EUDI operators must ensure strong certificate renewal processes with automated monitoring and early renewal to prevent certificate expiry from causing total service unavailability.
Preload commitment: Once a domain is added to the HSTS preload list, removal takes months because it requires updating browser source code and waiting for release cycles. EUDI operators must be certain they can maintain HTTPS across all subdomains before requesting preload inclusion.