Websicherheit gehosteter Seiten und der Front-API

Die gehostete Anmeldung, das Konto-Portal, die E-Mail-Seiten (Bestätigung, Passwort-Zurücksetzung, Einladung) und die Browser-API, die sie aufrufen, folgen auf jedem Tarif einer festen Grundlinie der Websicherheit. Diese Schutzmaßnahmen sind keine Einstellungen, die Sie abschalten können. Die einzige Einstellung, die Sie steuern, ist, welche Web-Ursprünge die OAuth-Endpunkte aus dem Browser aufrufen dürfen.

Cross-Site-Request-Forgery (CSRF)

Anfragen, die einen Zustand ändern, werden geprüft, bevor etwas gelesen oder geändert wird:

Prüfung des Ursprungs. Eine zustandsändernde Anfrage an die gehostete Anmelde-API oder an eine Bestätigungs- oder Zurücksetzungsseite muss einen Origin-Header tragen, der genau dem Anmeldehost der Umgebung entspricht. Jeder andere Ursprung wird mit origin_not_allowed abgelehnt.
Zustimmungsseite. Ein Formular-POST auf der Zustimmungsseite wird abgelehnt, wenn sein Origin nicht dem eigenen Host der Seite entspricht oder wenn Sec-Fetch-Site vorhanden ist und nicht same-origin lautet.
Formular-Token. Jede Anmeldetransaktion und jedes E-Mail-Formular hat ein eigenes CSRF-Token, das mit HMAC-SHA256 aus einem Schlüssel pro Umgebung abgeleitet wird. Die Anmelde-API erwartet es im Header Idp-Csrf-Token; das Token eines Formulars funktioniert nicht für ein anderes. Tokens werden in konstanter Zeit verglichen.
Cookies. Die Cookies, die den Anmeldezustand tragen, verwenden SameSite=Lax (siehe unten), sodass eine Anfrage, die von einer anderen Website gestartet wird, sie nicht mitsendet.

Anfragen über Ursprünge hinweg (CORS)

CORS wird nur an den OAuth-Endpunkten beantwortet, die eine Browser-Anwendung aufruft: dem Token-, Widerrufs-, Pushed-Authorization-Request- und Userinfo-Endpunkt. Es gilt nur für öffentliche Single-Page-Anwendungen (Typ spa).

Legen Sie die erlaubten Ursprünge pro Anwendung mit allowed_web_origins fest (https://host[:port], höchstens 20, keine Platzhalter). Siehe Anwendung anlegen.
Eine Preflight-Anfrage des Browsers sagt nicht, welche Anwendung aufruft, daher wird sie aus der Vereinigung der erlaubten Ursprünge der aktiven öffentlichen Single-Page-Anwendungen der Umgebung beantwortet. Die eigentliche Anfrage wird dann gegen die Ursprungsliste der aufrufenden Anwendung geprüft.
Ein Ursprung außerhalb der Liste dieser Anwendung wird mit 403 origin_not_allowed abgelehnt und erhält keinen Header Access-Control-Allow-Origin.
Ein erlaubter Ursprung wird genau zurückgegeben. * und null werden niemals gesendet, Access-Control-Allow-Credentials wird niemals gesendet, und jede Antwort über Ursprünge hinweg trägt Vary: Origin.
Anfragen vom Anmeldehost selbst gelten nicht als Anfragen über Ursprünge hinweg und sind nicht betroffen.

Weiterleitungen nach der Anmeldung

Wenn Sie das Next.js SDK verwenden, muss returnTo ein Pfad Ihrer eigenen App sein. Eine vollständige URL oder ein Wert wie //evil.example wird ignoriert, und der Benutzer landet auf /. Siehe Next.js SDK.

Sicherheits-Header

Gehostete Seiten setzen diese Header in jeder Antwort:

Header	Wert
`Content-Security-Policy`	`default-src 'none'`; Skripte nur mit einem frischen Nonce pro Antwort; `style-src 'self'`; `connect-src 'self'`; `frame-ancestors 'none'`; `base-uri 'none'`; `object-src 'none'`; `upgrade-insecure-requests`; Trusted Types für Skripte erforderlich
`Reporting-Endpoints` und `report-to`	Richtlinienverletzungen werden an `/u/csp-report` auf demselben Host gemeldet
`X-Frame-Options`	`DENY`: gehostete Seiten können nicht in einen Frame eingebettet werden
`X-Content-Type-Options`	`nosniff`
`Referrer-Policy`	`no-referrer`
`Cross-Origin-Opener-Policy`	`same-origin`
`Permissions-Policy`	Kamera, Mikrofon, Standort, Zahlung, USB, seriell, HID und Bluetooth sind deaktiviert; Passkey-Anfragen sind für die Seite selbst erlaubt
`Cache-Control`	`no-store`

Die Richtlinie erlaubt keine Inline-Skripte und keine unsafe--Schlüsselwörter. Formularübermittlungen sind auf den eigenen Host der Seite beschränkt; auf der Zustimmungsseite erlaubt die Richtlinie außerdem die Weiterleitungsadresse der anfragenden Anwendung, damit die Entscheidung dorthin zurückkehren kann.

Der Berichtsendpunkt akzeptiert nur Browser-Verletzungsberichte von höchstens 8 KiB und ist pro IP-Adresse ratenbegrenzt. Berichte werden nach Direktive gezählt. Beim Protokollieren enthalten sie keine Abfragezeichenfolge, kein Fragment und keine Benutzerinformationen.

Strict-Transport-Security

Umgebungshosts auf keenauth.app senden max-age=63072000; includeSubDomains.
Eine eigene Domain sendet nur max-age=63072000, ohne includeSubDomains. KeenAuth kann nicht für die anderen Subdomains Ihrer Domain entscheiden, daher bleibt diese Wahl bei Ihnen.

Cookies

Cookies für den Anmeldezustand tragen das Präfix __Host-, sodass ein Browser sie nur über HTTPS, mit Path=/ und ohne Attribut Domain akzeptiert. Sie können nicht von einer Schwester-Subdomain gesetzt werden.

Cookie	Flags	Zweck
`__Host-idp_session`	`Secure`, `HttpOnly`, `SameSite=Lax`	Die Sitzung des Benutzers. Ihre Laufzeit endet mit dem absoluten Ablauf der Sitzung
`__Host-idp_device`	`Secure`, `HttpOnly`, `SameSite=Lax`	Wiedererkennung des Geräts
`__Host-idp_ltx` und `__Host-idp_azr_*`	`Secure`, `HttpOnly`, `SameSite=Lax`	Bindet einen Anmelde- oder Autorisierungsversuch an den Browser, der ihn gestartet hat
`__Host-idp_fed_bind`	`Secure`, `HttpOnly`, `SameSite=None`	Kurzlebige Bindung für die Anmeldung über Unternehmens-SAML. Der Identitätsanbieter sendet von einer anderen Website zurück, daher würde `Lax` das Cookie verwerfen

Cookie-Werte sind für Seitenskripte nicht lesbar (HttpOnly).