Learn 2FA Authentication - Transport Hardening: HTTPS, Cookie & CSP

#Introduction

A TOTP code is a secret the user types every 30 seconds. Such a small secret can be kidnapped mid-journey if transport isn't secured. Episode 13 covers transport hardening: TLS in production, correct cookie attributes, and a Content-Security-Policy for the pages that display the QR.

These three layers work at different levels — TLS protects data on the network, cookies protect the session in the browser, and CSP limits what a page is allowed to load. You'll install all three and understand why a 2FA app without this hardening is like a padlock on a door with holes in the walls.

#HTTPS in Production

#TLS Is Mandatory, Not Optional

A TOTP code sent over plain HTTP can be read by anyone on the path between the user and the server. For a 2FA app, HTTPS isn't an improvement — it's a pre-requisite. Install a TLS certificate from Let's Encrypt via certbot, or use a reverse proxy like Caddy that manages certificates automatically:

sudo apt install certbot
sudo certbot --nginx -d auth.devvnull.dev
sudo certbot renew --dry-run

The certbot renew --dry-run command verifies that automatic certificate renewal is running. An expired certificate is a common cause of an app suddenly failing authentication.

Besides serving HTTPS, make sure internal requests between services don't travel over unencrypted protocols — a 2FA secret moving between components is also a secret worth protecting.

#Redirect HTTP to HTTPS

All HTTP traffic must be redirected to HTTPS. In Express, a simple redirect forces the browser to move to the secure version:

Redirect HTTP to HTTPS

app.use((req, res, next) => {
  if (req.secure || req.headers['x-forwarded-proto'] === 'https') {
    return next();
  }
  return res.redirect('https://' + req.headers.host + req.url);
});

The middleware checks the x-forwarded-proto header for the case of an app behind a reverse proxy. In Next.js, a permanent redirect can simply be configured at the framework or edge level.

A special note: in a development environment, the secure cookie flag can be disabled so local HTTPS isn't required, but in production the redirect and secure cookie must not be switchable through an easily missed configuration.

#Secure Cookies

#Secure, HttpOnly, and SameSite

The session cookie must use all three attributes at once. Secure only allows the cookie to be sent over HTTPS. HttpOnly hides it from JavaScript, making it resistant to XSS. SameSite restricts sending the cookie on cross-site requests to fend off CSRF:

Secure session cookie configuration

app.use(session({
  name: 'sid',
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,
    secure: true,
    sameSite: 'lax',
    maxAge: 15 * 60 * 1000
  }
}));

The sameSite: 'lax' value is a good balance: normal navigation still carries the cookie, while malicious cross-site POST requests don't. Use strict only if the app's flow doesn't need the cookie on external navigation.

The maxAge attribute also needs tuning: the shorter it is, the smaller the window for abusing a stolen cookie. A regular session is 15 minutes, while the pendingMfa state is much shorter.

#Separate Cookies for Sensitive State

Consider a separate cookie for very sensitive state, such as pendingMfa from episode 8. A short, isolated MFA cookie reduces the surface if the main session leaks. Episode 15 will use this pattern for trusted devices.

#Content-Security-Policy

#Restricting Sources on the Enrollment Page

The Enable 2FA page loads a QR code and a secret — two things that must not be stolen by scripts from foreign sources. Content-Security-Policy restricts where scripts, styles, and images may be loaded from:

Content-Security-Policy: default-src 'self';
  script-src 'self';
  img-src 'self' data:;
  style-src 'self' 'unsafe-inline';
  frame-ancestors 'none'

The img-src 'self' data: rule allows the QR image sent as a data URL. frame-ancestors 'none' prevents your page from being displayed inside another site's iframe — closing the clickjacking gap.

#Secure the Page That Loads the QR

CSP applies per page. The page holding the 2FA secret can use a stricter policy than public pages: no external scripts, no CDN styles, no embeds of any kind. The fewer sources allowed, the narrower the attack surface.

Also apply the Referrer-Policy and X-Content-Type-Options headers as a default habit; both prevent URL leakage in the referrer and content-type sniffing on pages holding sensitive data.

#Conclusion

Episode 13 hardened transport and headers: TLS with an HTTP redirect, session cookies with the Secure, HttpOnly, and SameSite attributes, and a Content-Security-Policy that restricts the enrollment page's sources.

The key takeaways:

• HTTPS is an absolute pre-requisite for any app using TOTP.
• Redirect all HTTP traffic to HTTPS.
• Session cookies must be Secure, HttpOnly, and SameSite.
• Consider a separate cookie for sensitive MFA state.
• CSP restricts script and image sources on the enrollment page.
• frame-ancestors none closes the clickjacking gap.

In the next episode, episode 14, we will cover OWASP and security best practices — server-side-only verification, timing-safe comparison, the prohibition on logging secrets and codes, and why you should never write TOTP yourself from scratch.