Controllo degli accessi

Il controllo degli accessi è l'insieme dei meccanismi che decidono se un dato soggetto (utente, servizio o token) possa eseguire una data azione su una data risorsa. Sul web combina autenticazione (chi sei) e autorizzazione (cosa puoi fare), ed è la categoria dietro al rischio OWASP "Broken Access Control". Va imposto lato server a ogni richiesta, mai nascondendo semplicemente un pulsante nell'interfaccia.

Autenticazione

L'autenticazione è il processo di verifica che un principal sia chi dichiara di essere, tipicamente tramite password, passkey, codice usa-e-getta o chiave crittografica. Stabilisce l'identità ma non dice nulla sui permessi, che sono compito dell'autorizzazione. Un'autenticazione debole o assente (credential stuffing, niente MFA, ID di sessione prevedibili) è una causa primaria di furto di account.

Autorizzazione

L'autorizzazione determina cosa un principal autenticato è abilitato a fare, applicando regole come il controllo accessi basato su ruoli o attributi. Ogni operazione protetta deve riverificare l'autorizzazione sul server usando la nozione di identità del server, non un ruolo o un ID oggetto forniti dal client. Non farlo produce broken access control, incluso l'IDOR.

Broken Object Level Authorization (BOLA)

Il BOLA, chiamato anche IDOR, si verifica quando un'API espone un identificatore di oggetto e non verifica che il chiamante sia autorizzato ad accedere a quello specifico oggetto. Un attaccante cambia semplicemente l'ID nella richiesta (per esempio da /orders/123 a /orders/124) per leggere o modificare i dati di un altro tenant. È il rischio numero uno nella OWASP API Security Top 10.

Attacco a forza bruta

Un attacco a forza bruta prova molte credenziali o valori in modo sistematico finché uno non funziona, per esempio indovinando password, token di sessione o codici TOTP. Le difese includono rate limiting, blocco o throttling dell'account, policy di password robuste, MFA e token ad alta entropia. Il credential stuffing è una variante mirata che rigioca coppie username/password trafugate da altre violazioni.

Certificate Authority (CA)

Una certificate authority è un'entità fidata che emette certificati digitali legando una chiave pubblica a un'identità come un nome di dominio. I browser includono un root store di CA fidate; un certificato TLS è fidato se si concatena a una di quelle radici ed è non scaduto e non revocato. Let's Encrypt è una CA molto usata che offre certificati gratuiti, automatizzati e a breve durata.

Clickjacking

Il clickjacking inganna l'utente facendogli cliccare qualcosa di diverso da ciò che percepisce, sovrapponendo o incorniciando un sito bersaglio dentro una pagina dell'attaccante, di solito con un iframe trasparente. L'utente crede di interagire con l'interfaccia dell'attaccante ma i suoi clic finiscono sul sito incorniciato. Si mitiga inviando una direttiva restrittiva Content-Security-Policy: frame-ancestors (o il legacy X-Frame-Options).

Content Security Policy (CSP)

La Content Security Policy è un header di risposta HTTP che indica al browser quali sorgenti di script, stile, immagini e altri contenuti possano essere caricate ed eseguite. Un script-src rigoroso basato su nonce o hash è una delle difese più efficaci contro il cross-site scripting, perché gli script inline iniettati senza il nonce corretto vengono bloccati. La CSP è difesa in profondità, non un sostituto dell'output encoding.

Il CORS è un meccanismo del browser che allenta in modo controllato la same-origin policy, lasciando che un server acconsenta a richieste cross-origin tramite Access-Control-Allow-Origin e header correlati. È imposto dal browser, non dal server, e protegge l'utente: non è un meccanismo di autenticazione né di controllo accessi lato server. Riflettere l'Origin della richiesta con le credenziali abilitate è una pericolosa configurazione errata comune.

Cross-Site Request Forgery (CSRF)

Il CSRF costringe il browser di un utente autenticato a inviare una richiesta non voluta e modificante lo stato verso un sito dove è autenticato, abusando dell'inclusione automatica dei cookie da parte del browser. Si mitiga con token anti-CSRF (synchronizer o double-submit) e con l'attributo cookie SameSite. Il CSRF colpisce l'autenticazione di sessione basata su cookie; le API che si autenticano con un bearer token in un header generalmente non vi sono esposte.

Cross-Site Scripting (XSS)

L'XSS è una falla di injection in cui un attaccante fa eseguire al browser script controllato dall'attaccante nel contesto di un sito fidato, permettendogli di rubare token di sessione, agire come l'utente o deturpare le pagine. Le tre forme classiche sono XSS stored, reflected e DOM-based. La difesa primaria è l'output encoding consapevole del contesto unito a una Content Security Policy rigorosa.

Difesa in profondità

La difesa in profondità sovrappone più controlli indipendenti, così che il fallimento di uno non comprometta l'intero sistema. Per un'app web significa validazione dell'input, output encoding, query parametrizzate, account a privilegio minimo, segmentazione di rete e monitoraggio che lavorano insieme. Nessun singolo controllo (come un WAF) va considerato sufficiente da solo.

XSS DOM-based

L'XSS DOM-based è una variante di cross-site scripting in cui la vulnerabilità vive interamente nel JavaScript lato client, che prende dati controllabili dall'attaccante da una sorgente (come location.hash) e li passa a un sink pericoloso (come innerHTML o eval) senza sanitizzazione. Poiché il payload può non raggiungere mai il server, il filtraggio lato server non lo ferma. Usa invece sink sicuri come textContent e il binding fornito dal framework.

Cifratura a riposo

La cifratura a riposo protegge i dati memorizzati - database, backup, dischi, object storage - affinché il furto fisico o l'accesso non autorizzato al livello di storage non esponga testo in chiaro. È distinta dalla cifratura in transito (TLS), ed entrambe sono di solito necessarie. La parte difficile è la gestione delle chiavi, non il cifrario: le chiavi vanno conservate e ruotate separatamente dai dati che proteggono.

HTTP Strict Transport Security (HSTS)

L'HSTS è un header di risposta (Strict-Transport-Security) che istruisce il browser a contattare un sito solo tramite HTTPS per un periodo specificato, prevenendo attacchi di downgrade di protocollo e di SSL-stripping. Una volta che il browser ha visto l'header, rifiuta connessioni in HTTP semplice verso quell'host anche se l'utente digita http://. Il preloading aggiunge il dominio a una lista distribuita col browser, così anche la prima richiesta è protetta.

IDOR (Insecure Direct Object Reference)

L'IDOR è un broken access control in cui l'applicazione usa input fornito dall'utente per accedere direttamente a un oggetto senza verificare che l'utente vi sia autorizzato. Sinonimo nella pratica di Broken Object Level Authorization, permette agli attaccanti di enumerare e raggiungere i record di altri utenti alterando un identificatore. La correzione è un controllo di proprietà/permesso lato server a ogni accesso all'oggetto, non solo ID non indovinabili.

Injection

Le falle di injection si verificano quando dati non fidati vengono inviati a un interprete (SQL, shell del SO, LDAP, NoSQL, motore di template) come parte di un comando o di una query, permettendo all'attaccante di alterarne il significato. SQL injection e command injection sono gli esempi classici. La difesa robusta è tenere separati codice e dati con query parametrizzate, API sicure e validazione dell'input in allow-list.

JSON Web Token (JWT)

Un JWT è un token compatto, URL-safe, firmato (e opzionalmente cifrato) che trasporta claim come payload JSON, comunemente usato per autenticazione e autorizzazione stateless. Ha tre parti Base64url - header, payload, firma - separate da punti; il payload è firmato, non segreto, quindi non metterci mai dati riservati non cifrati. Verifica sempre la firma e rifiuta il valore alg: none e gli algoritmi inattesi.

Privilegio minimo

Il principio del privilegio minimo afferma che ogni utente, processo e service account dovrebbe avere solo i permessi strettamente necessari a svolgere il proprio compito, e niente di più. Applicato alle app web significa token API con scope ridotto, utenti di database limitati alle tabelle necessarie e credenziali a breve durata. Limita il raggio d'impatto quando un singolo componente viene compromesso.

Autenticazione multi-fattore (MFA)

L'MFA richiede due o più fattori indipendenti per autenticarsi: qualcosa che sai (password), qualcosa che hai (una chiave di sicurezza o un'app authenticator) o qualcosa che sei (biometrico). Riduce drasticamente il furto di account da phishing e credential stuffing, perché una password rubata da sola non basta. L'MFA resistente al phishing basata su WebAuthn/FIDO2 è più forte di SMS o codici TOTP.

OAuth 2.0

OAuth 2.0 è un framework di autorizzazione che permette a un'applicazione di ottenere accesso limitato e delegato alle risorse di un utente su un altro servizio senza gestire la password dell'utente, scambiando una concessione di autorizzazione con un access token. Serve all'autorizzazione delegata, non all'autenticazione; OpenID Connect è il livello di identità costruito sopra. I client pubblici dovrebbero usare l'Authorization Code flow con PKCE.

OpenID Connect (OIDC)

OpenID Connect è un livello di autenticazione costruito su OAuth 2.0 che aggiunge un ID token (un JWT firmato) che descrive l'utente autenticato, oltre a un endpoint userinfo standardizzato e a un documento di discovery. Permette alle relying party di verificare l'identità di un utente e ottenere claim di profilo di base da un identity provider. OIDC risponde a "chi è l'utente?" mentre OAuth puro risponde a "a cosa può accedere questa app?".

Output encoding

L'output encoding trasforma i dati affinché siano resi come testo inerte anziché codice eseguibile nel contesto in cui appaiono (corpo HTML, attributo HTML, JavaScript, URL, CSS). È la difesa primaria contro il cross-site scripting e deve essere consapevole del contesto, perché l'escaping corretto differisce per contesto. I framework moderni codificano per default, ma i sink HTML grezzi aggirano quella protezione.

Query parametrizzata

Una query parametrizzata (prepared statement) invia al database separatamente la struttura del comando SQL e i valori forniti dall'utente, così che i valori non possano mai essere interpretati come codice SQL. È la difesa definitiva contro la SQL injection e va usata per ogni query che contiene dati variabili. La concatenazione di stringhe per costruire SQL è l'anti-pattern che essa sostituisce.

PKCE (Proof Key for Code Exchange)

PKCE è un'estensione di OAuth 2.0 che protegge l'authorization code flow dall'intercettazione legando lo scambio del codice a un segreto per-richiesta. Il client invia un code_challenge con hash quando richiede il codice e il corrispondente code_verifier quando lo riscatta, così un codice di autorizzazione rubato è inutile per un attaccante. È obbligatorio per i client pubblici (SPA, mobile) e raccomandato per tutti i client in OAuth 2.1.

Rate limiting

Il rate limiting limita quante richieste un client può fare in una finestra temporale, attenuando o rifiutando il traffico in eccesso per proteggere da forza bruta, credential stuffing, scraping e denial-of-service. Può basarsi su IP, account, API key o token, ed è spesso implementato con algoritmi token-bucket o sliding-window. Abbinalo a backoff esponenziale e a chiare risposte 429 Too Many Requests.

Same-Origin Policy (SOP)

La same-origin policy è il modello di sicurezza fondamentale del browser che limita come un documento o uno script caricato da un'origine possa interagire con le risorse di un'altra origine, dove l'origine è la tupla di schema, host e porta. Impedisce a una pagina malevola di leggere le risposte o il DOM di un altro sito. Il CORS è il meccanismo controllato per allentarla per specifiche richieste cross-origin.

SameSite è un attributo cookie che controlla se il cookie venga inviato nelle richieste cross-site, con valori Strict, Lax e None. Lax (un default comune) blocca il cookie sulle sottorichieste cross-site e sui form POST pur consentendo le navigazioni top-level, offrendo una difesa CSRF significativa. None richiede il flag Secure e invia il cookie cross-site, necessario per alcune integrazioni di terze parti.

Gli attributi Secure, HttpOnly e SameSite rafforzano i cookie di sessione: Secure limita il cookie a HTTPS, HttpOnly lo nasconde a JavaScript (limitando il furto via XSS) e SameSite vincola l'invio cross-site (limitando il CSRF). I cookie di sessione dovrebbero normalmente impostarli tutti e tre. Il prefisso __Host- impone inoltre Secure, nessun Domain e Path=/.

Configurazione errata di sicurezza

La configurazione errata di sicurezza è il rischio di impostazioni di default insicure, configurazioni incomplete, messaggi di errore verbosi, funzionalità inutilizzate lasciate attive o header di sicurezza mancanti. È uno dei rischi web più comuni e facilmente sfruttabili perché non richiede una falla di codice. Baseline di hardening, scansione automatica della configurazione e rimozione dei default lo riducono.

Server-Side Request Forgery (SSRF)

L'SSRF inganna un server inducendolo a effettuare richieste HTTP verso una destinazione scelta dall'attaccante, spesso per raggiungere servizi interni, endpoint di metadati cloud o host altrimenti irraggiungibili. È pericoloso negli ambienti cloud dove il servizio di metadati (169.254.169.254) può fornire credenziali. Si mitiga con allow-list rigorose di destinazioni, bloccando i range link-local e interni e disabilitando schemi URL e redirect inutilizzati.

Session fixation

La session fixation è un attacco in cui l'attaccante imposta o conosce l'identificatore di sessione della vittima prima del login e poi dirotta la sessione autenticata dopo. La correzione è emettere un nuovo identificatore di sessione nel momento in cui cambia il privilegio - soprattutto subito dopo un'autenticazione riuscita - e invalidare quello vecchio. Non accettare mai ID di sessione forniti nell'URL.

Gestione delle sessioni

La gestione delle sessioni è il modo in cui un'applicazione stabilisce, mantiene e termina lo stato autenticato di un utente attraverso richieste HTTP stateless, tipicamente via cookie di sessione o token. Le sessioni sicure usano identificatori ad alta entropia, ruotano l'ID al login, impostano attributi cookie sicuri, applicano timeout di inattività e assoluti e invalidano al logout. Una gestione debole delle sessioni abilita hijacking e fixation.

SQL Injection (SQLi)

La SQL injection è una falla di injection in cui input controllato dall'attaccante altera la struttura di una query SQL, permettendo furto di dati, modifica, bypass dell'autenticazione e in alcuni casi esecuzione di comandi. Resta tra le vulnerabilità web più dannose. La correzione affidabile sono le query parametrizzate (prepared statement) con account di database a privilegio minimo e validazione in allow-list come difesa in profondità.

Subresource Integrity (SRI)

La Subresource Integrity permette a una pagina di garantire che uno script o un foglio di stile ospitato esternamente non sia stato manomesso, aggiungendo un attributo integrity che contiene un hash crittografico del file atteso. Il browser scarica la risorsa e ne rifiuta l'esecuzione se l'hash non corrisponde. La SRI difende dai CDN compromessi ed è tipicamente abbinata all'attributo crossorigin.

Attacco alla supply chain

Un attacco alla supply chain compromette il software colpendo una dipendenza upstream fidata, uno strumento di build o un canale di distribuzione anziché direttamente l'applicazione bersaglio. Esempi includono pacchetti npm malevoli, typosquatting e pipeline CI compromesse. Le difese includono lockfile, pinning e verifica delle dipendenze, SBOM, sistemi di build a privilegio minimo e Subresource Integrity per gli script di terze parti.

Threat modeling

Il threat modeling è un'attività strutturata per identificare, enumerare e dare priorità alle minacce potenziali a un sistema fin dalla progettazione, così che i controlli possano essere pianificati anziché aggiunti dopo. Un approccio comune è STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) applicato a un diagramma di flusso dei dati. Risponde a cosa può andare storto e cosa farci.

TLS (Transport Layer Security)

Il TLS è il protocollo crittografico che protegge i dati in transito tra client e server, fornendo riservatezza, integrità e autenticazione del server (opzionalmente del client); è alla base di HTTPS. TLS 1.3 è la versione attualmente raccomandata, che rimuove i cifrari legacy e riduce l'handshake a un solo round trip. Una configurazione errata (cifrari deboli, certificati scaduti, HSTS mancante) ne mina la protezione.

Conservazione dei token

La conservazione dei token è la decisione su dove un client web tenga credenziali come access token e refresh token. Il localStorage è leggibile da qualsiasi JavaScript sulla pagina, quindi un singolo XSS può esfiltrare i token; i cookie HttpOnly sono inaccessibili agli script ma richiedono difese CSRF. Il compromesso (esposizione all'XSS contro superficie CSRF) va deciso deliberatamente, non per default.

WebAuthn / FIDO2

WebAuthn è uno standard W3C, parte del progetto FIDO2, che abilita autenticazione passwordless e resistente al phishing usando crittografia a chiave pubblica e authenticator come chiavi di sicurezza, biometria di piattaforma o passkey. La chiave privata non lascia mai l'authenticator e la firma è legata all'origine, vanificando phishing e replay delle credenziali. È il meccanismo di autenticazione web più forte ampiamente disponibile.

Web Application Firewall (WAF)

Un WAF ispeziona il traffico HTTP e blocca le richieste che corrispondono a pattern di attacco noti (SQLi, XSS, path traversal) prima che raggiungano l'applicazione. Fornisce un'utile difesa in profondità e virtual patching, ma è un filtro aggirabile e non deve mai sostituire la scrittura di codice sicuro. Tratta gli alert del WAF come segnale, non come garanzia che la falla sottostante sia corretta.

Zero Trust

Lo zero trust è un modello di sicurezza che non assume alcuna fiducia implicita basata sulla posizione di rete e verifica invece l'identità, il dispositivo e il contesto di ogni richiesta prima di concedere accesso. "Mai fidarsi, sempre verificare" sostituisce il vecchio modello perimetrale in cui essere dentro la rete significava essere fidati. Per i sistemi web implica autenticazione e autorizzazione per ogni richiesta, identità forte e privilegio minimo ovunque.