Security notes

Frontdoor sits in front of your internal applications and handles authentication. This page sums up how it protects them and what is up to you.

Sign-in and sessions

• The OAuth flow uses PKCE (S256) and a single-use state stored on the server for 10 minutes. The state is bound to the browser that started the sign-in through a short-lived httpOnly cookie (frontdoor_auth_nonce). The code verifier never leaves the server.
• Tokens from Microsoft are validated by the MSAL library, with signature checks against Microsoft's public keys.
• The session token Frontdoor issues is stored only in an httpOnly cookie, not readable by JavaScript. The user profile sent to the browser does not include the token.
• People listed in ADMIN_EMAILS are promoted to owner at sign-in and cannot be demoted from the web interface.

Built-in hardening

• Content Security Policy through Helmet, with a per-response form-action allowance for SSO POST redirects.
• Parameterized SQL everywhere, no string interpolation.
• Sanitization: pasted SVG icons and rich text pass through DOMPurify; HTML tags are stripped from user-supplied text fields.
• Cross-site request check: requests that change data with the session cookie must come from Frontdoor or from an origin in CORS_ALLOWED_ORIGINS.
• Rate limiting on sign-in, the API, group and user changes, and the token introspection endpoint. The first three are tunable (see Configuration reference); the introspection limit is fixed at 120 requests per minute.
• No personal data in logs: emails, names and tokens are never written to the server console.
• Startup validation: Frontdoor stops at startup if a required secret is missing.

What you must get right

• Use a unique, random JWT_SECRET of at least 32 characters.
• Rotate the Entra client secret periodically and never commit it to source control.
• Never expose Dev Login. It lets anyone pick any role, and the demo profile signs tokens with a public fallback secret. Production (NODE_ENV=production) always disables it.
• Share JWT_SECRET only with fully trusted apps: an app that holds it can verify Frontdoor tokens, but could also sign them. Use token introspection for the others. See Authentication for satellite apps.
• List in CORS_ALLOWED_ORIGINS only the origins that really need to call Frontdoor with credentials.

Report a vulnerability

Do not open a public issue for a security vulnerability. Use GitHub's private vulnerability reporting on the Frontdoor repository (Security → Report a vulnerability). If that option is not available, contact a maintainer through GitHub and ask for a private channel.

Include:

• a description of the issue and the impact you observed
• steps to reproduce, or a minimal proof of concept
• the affected version or commit
• your assessment of severity, if you have one

Stage	Target
Acknowledgement of the report	within 72 hours
Initial severity assessment	within 7 days
Fix for critical issues	within 30 days of confirmation
Coordinated public disclosure	after a fix is released, or by mutual agreement

Only the latest minor release of 1.x is supported, so keep your installation up to date (see Upgrade and rollback).

Good-faith research that follows this policy will not be pursued legally: avoid degrading the service for others, do not access or change data that is not yours, and give the maintainers reasonable time to fix the issue before disclosing it.