Sicurezza web delle pagine ospitate e dell'API frontend

L'accesso ospitato, il portale account, le pagine email (verifica, reimpostazione della password, invito) e l'API del browser che esse chiamano seguono una base di sicurezza web fissa su ogni piano. Queste protezioni non sono impostazioni che puoi disattivare. L'unica impostazione che controlli è quali origini web possono chiamare dal browser gli endpoint OAuth.

Cross-site request forgery (CSRF)

Le richieste che modificano lo stato vengono verificate prima che venga letto o modificato qualsiasi dato:

Controllo dell'origine. Una richiesta che modifica lo stato verso l'API di accesso ospitata o verso una pagina di verifica o reimpostazione deve includere un header Origin esattamente uguale all'host di accesso dell'ambiente. Qualsiasi altra origine viene rifiutata con origin_not_allowed.
Schermata di consenso. Un invio di form sulla schermata di consenso viene rifiutato quando il suo Origin non è l'host della pagina stessa, oppure quando Sec-Fetch-Site è presente e non vale same-origin.
Token dei form. Ogni transazione di accesso e ogni form email ha un proprio token CSRF, derivato con HMAC-SHA256 da una chiave per ambiente. L'API di accesso lo attende nell'header Idp-Csrf-Token; il token di un form non funziona per un altro. I token sono confrontati in tempo costante.
Cookie. I cookie che trasportano lo stato di accesso usano SameSite=Lax (vedi sotto), quindi una richiesta avviata da un altro sito non li invia.

Richieste cross-origin (CORS)

CORS viene gestito solo sugli endpoint OAuth che un'applicazione browser chiama: l'endpoint dei token, di revoca, della richiesta di autorizzazione pushed e di userinfo. Si applica solo alle applicazioni single-page pubbliche (tipo spa).

Imposta le origini consentite per applicazione con allowed_web_origins (https://host[:port], al massimo 20, senza wildcard). Vedi Crea un'applicazione.
La richiesta di preflight del browser non indica quale applicazione sta chiamando, quindi riceve risposta dall'unione delle origini consentite delle applicazioni single-page pubbliche attive dell'ambiente. La richiesta effettiva viene poi verificata rispetto all'elenco di origini dell'applicazione che chiama.
Un'origine fuori dall'elenco di quell'applicazione viene rifiutata con 403 origin_not_allowed e non riceve alcun header Access-Control-Allow-Origin.
Un'origine consentita viene restituita esattamente così com'è. * e null non vengono mai inviati, Access-Control-Allow-Credentials non viene mai inviato, e ogni risposta cross-origin include Vary: Origin.
Le richieste dall'host di accesso stesso non sono cross-origin e non sono interessate.

Reindirizzamenti dopo l'accesso

Se usi l'SDK Next.js, returnTo deve essere un percorso della tua app. Un URL completo o un valore come //evil.example viene ignorato e l'utente finisce su /. Vedi SDK Next.js.

Header di sicurezza

Le pagine ospitate impostano questi header in ogni risposta:

Header	Valore
`Content-Security-Policy`	`default-src 'none'`; script solo con un nonce nuovo per ogni risposta; `style-src 'self'`; `connect-src 'self'`; `frame-ancestors 'none'`; `base-uri 'none'`; `object-src 'none'`; `upgrade-insecure-requests`; Trusted Types richiesti per gli script
`Reporting-Endpoints` e `report-to`	Le violazioni della policy vengono segnalate a `/u/csp-report` sullo stesso host
`X-Frame-Options`	`DENY`: le pagine ospitate non possono essere incorporate in un frame
`X-Content-Type-Options`	`nosniff`
`Referrer-Policy`	`no-referrer`
`Cross-Origin-Opener-Policy`	`same-origin`
`Permissions-Policy`	Fotocamera, microfono, geolocalizzazione, pagamento, USB, seriale, HID e Bluetooth sono disattivati; le richieste di passkey sono consentite per la pagina stessa
`Cache-Control`	`no-store`

La policy non consente script inline né parole chiave unsafe-. L'invio dei form è limitato all'host della pagina; sulla schermata di consenso la policy consente anche l'indirizzo di reindirizzamento dell'applicazione che chiede l'accesso, così che la decisione possa tornare a essa.

L'endpoint di segnalazione accetta solo segnalazioni di violazione del browser di al massimo 8 KiB, ed è soggetto a limite di frequenza per indirizzo IP. Le segnalazioni vengono conteggiate per direttiva. Quando vengono registrate non contengono query string, frammenti o informazioni sull'utente.

Strict-Transport-Security

Gli host dell'ambiente su keenauth.app inviano max-age=63072000; includeSubDomains.
Un dominio personalizzato invia solo max-age=63072000, senza includeSubDomains. KeenAuth non può decidere per gli altri sottodomini del tuo dominio, quindi questa scelta resta a te.

I cookie di stato dell'accesso hanno nomi con il prefisso __Host-, quindi un browser li accetta solo su HTTPS, con Path=/ e senza attributo Domain. Non possono essere impostati da un sottodominio fratello.

Cookie	Flag	Scopo
`__Host-idp_session`	`Secure`, `HttpOnly`, `SameSite=Lax`	La sessione dell'utente. La sua durata termina alla scadenza assoluta della sessione
`__Host-idp_device`	`Secure`, `HttpOnly`, `SameSite=Lax`	Riconoscimento del dispositivo
`__Host-idp_ltx` e `__Host-idp_azr_*`	`Secure`, `HttpOnly`, `SameSite=Lax`	Associa un tentativo di accesso o di autorizzazione al browser che lo ha avviato
`__Host-idp_fed_bind`	`Secure`, `HttpOnly`, `SameSite=None`	Associazione di breve durata per l'accesso SAML aziendale. Il provider di identità invia i dati di ritorno da un altro sito, quindi `Lax` lo scarterebbe

I valori dei cookie non sono leggibili dagli script della pagina (HttpOnly).