Verifichi Secure, HttpOnly e SameSite dei cookie
Un cookie di sessione con Secure, HttpOnly e SameSite=Lax supera il controllo, perché ha tutte e tre le protezioni. Incolli un cookie di un accesso o dopo una modifica al proxy e individui subito l’attributo mancante. Gratis nel suo browser.
- Gratis
- Funziona nel suo browser
- Senza registrazione
- I suoi dati restano sul dispositivo
Esegui gratis nel browser
Esempio risolto
- Testo
- session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
- Nome del cookie
- session_id
La sicurezza di un cookie dipende da piccoli attributi che possono essere omessi facilmente durante una modifica della configurazione. Questo strumento legge un valore dell’intestazione Set-Cookie, conferma che inizi con un nome e un valore e segnala la presenza di Secure, HttpOnly e SameSite. Restituisce inoltre un elenco chiaro degli attributi mancanti, utile per revisioni, distribuzioni, test e pipeline CI. Il controllo è deterministico, non distingue maiuscole e minuscole nei nomi degli attributi e non effettua richieste di rete.
Che cosa esamina lo strumento
Incolli il valore di una sola intestazione di risposta Set-Cookie, iniziando dal nome e dal valore del cookie. Lo strumento separa la prima coppia name=value dagli attributi delimitati da punti e virgola. Cerca quindi Secure, HttpOnly e SameSite senza dipendere dalle maiuscole.
Questa struttura è adatta sia a un controllo umano sia a una regola automatizzata. La verifica riguarda soltanto la presenza dei tre attributi: non garantisce che ambito, durata, progettazione del cookie o comportamento dell’applicazione siano sicuri. Un risultato completo rappresenta pertanto un controllo specifico della configurazione, non una valutazione generale della sicurezza web.
Come interpretare ogni attributo
Secure indica ai client compatibili di inviare il cookie soltanto tramite un trasporto sicuro. SameSite controlla quando il browser include il cookie nei diversi contesti di richieste tra siti e viene spesso usato nelle difese contro richieste contraffatte. Lo strumento segnala la presenza, ma non sceglie la politica SameSite corretta, perché Strict, Lax e None soddisfano esigenze diverse.
Un’integrazione tra siti, per esempio, può richiedere SameSite=None insieme a Secure. Lei valuti i risultati considerando la funzione del cookie, la sensibilità dell’autenticazione, il supporto dei browser e i flussi tra siti previsti.
Utilizzo nello sviluppo e nella CI
Esegua il controllo su valori Set-Cookie rappresentativi acquisiti dai test dell’applicazione, dal proxy inverso o dall’output del framework. Un input privo della coppia name=value iniziale viene rifiutato. Dopo una correzione, verifichi nuovamente la risposta effettivamente emessa, perché middleware, proxy, CDN o componenti di autenticazione possono modificare gli attributi.
Casi d'uso
Esaminare i cookie di autenticazione
Verifichi un cookie di sessione emesso all’accesso e individui subito uno dei tre attributi mancanti.
Convalidare le modifiche al proxy
Confronti le intestazioni dopo una modifica al proxy inverso o alla CDN per rilevare attributi persi durante la riscrittura.
Domande frequenti
Quanto costa il controllo?
La versione nel browser può funzionare localmente senza inviare l’intestazione a un servizio di rete.
Viene convalidato il valore di SameSite?
No. Lo strumento indica se SameSite è presente. La scelta tra Lax, Strict e None dipende dal comportamento tra siti richiesto.
I nomi degli attributi distinguono maiuscole e minuscole?
No. Secure, HttpOnly e SameSite vengono riconosciuti con qualsiasi combinazione di maiuscole e minuscole.
Perché il mio input è stato rifiutato?
Il valore deve iniziare con un nome di cookie non vuoto, seguito da un segno uguale e dal valore, prima degli attributi separati da punti e virgola.
Posso controllare più cookie insieme?
No, controlli un cookie alla volta. Unire più cookie in una sola riga separata da virgole non è affidabile, perché valori e date di scadenza possono contenere caratteri che rompono la separazione. Li incolli uno per uno.
Strumenti correlati
Per sviluppatori — accesso via API
Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.
Endpoint
Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.
Chiamala dal tuo stack
curl -X POST https://api.kit.forhosting.com/security/cookie-attribute-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"}'const res = await fetch("https://api.kit.forhosting.com/security/cookie-attribute-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/security/cookie-attribute-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/security/cookie-attribute-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/security/cookie-attribute-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Esempio di richiesta
{
"text": "session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"
}Esempio di risposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "security.cookie_attribute_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.
Prezzi
Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.
Errori
| HTTP | Codice | Significato |
|---|---|---|
401 | unauthorized | Chiave API mancante o non valida: controlla l'header Authorization. |
402 | insufficient_balance | Credito esaurito: ricarica per continuare a eseguire attività. |
404 | unknown_type | Tipo di attività sconosciuto: controlla il campo type della richiesta. |
429 | rate_limited | Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo. |
Note tecniche
Che cosa esamina lo strumento
Il risultato contiene un booleano per ogni protezione, un elenco ordinato degli attributi mancanti e il riepilogo `all_present`.
Come interpretare ogni attributo
HttpOnly impedisce al normale JavaScript lato client di leggere il cookie attraverso le comuni API del browser, riducendo le possibilità di sottrarre un token di sessione.
Utilizzo nello sviluppo e nella CI
In un test automatico, interrompa la build quando `all_present` è falso oppure applichi una politica mirata leggendo i tre booleani e `missing_attributes`. Poiché il parser è deterministico e non usa la rete, lo stesso input produce lo stesso output nel browser e tramite API. Inoltri una sola intestazione per richiesta: combinare più Set-Cookie crea ambiguità.
Casi di integrazione
Aggiungere una regola di sicurezza alla CI
Invii all’API un valore Set-Cookie ricavato da un test di integrazione e blocchi la pipeline quando `all_present` è falso.
Domande tecniche
Posso controllare più intestazioni Set-Cookie insieme?
No. Inoltri un solo valore Set-Cookie per richiesta per ottenere un risultato inequivocabile per ogni cookie.