Metodi HTTP pericolosi: come vengono annunciati TRACE, PUT e DELETE
I server HTTP possono annunciare i metodi che supportano rispondendo a una richiesta OPTIONS. Quando quella lista include metodi pericolosi — TRACE, PUT, DELETE, PATCH o CONNECT — non necessari in produzione, consegni agli attaccanti una mappa dei potenziali punti di ingresso. AppSafe invia una richiesta OPTIONS all'URL radice del tuo sito e segnala qualsiasi metodo pericoloso negli header Allow o Access-Control-Allow-Methods.
Che cos'è
Ogni server HTTP può rispondere a una richiesta OPTIONS con un header Allow che elenca i metodi accettati: GET, POST, HEAD, OPTIONS e qualsiasi altro supporti. Alcuni framework e reverse proxy aggiungono Access-Control-Allow-Methods alla stessa risposta. Nessun header è obbligatorio, ma quando presenti indicano a qualsiasi client esattamente quali verbi provare.
AppSafe invia una richiesta OPTIONS alla tua origine e controlla entrambi gli header alla ricerca di metodi in una breve lista di pericolo: TRACE, PUT, PATCH, DELETE e CONNECT. TRACE ottiene il proprio risultato ad alta severità; gli altri vengono raggruppati a severità media. La verifica riguarda esclusivamente l'annuncio — un metodo elencato in Allow può o meno fare qualcosa sul tuo server, ma elencarlo incoraggia l'esplorazione.
Perché è importante
TRACE è il più grave. Riflette l'intera richiesta — compresi tutti gli header — al chiamante. In ambienti dove le credenziali o i cookie di sessione vengono trasmessi come header di richiesta, questo riflesso potrebbe esporre quei valori a uno script nella pagina tramite cross-site tracing (XST). I browser moderni bloccano TRACE via XHR/fetch, ma proxy e load balancer potrebbero non farlo. TRACE non ha alcun uso legittimo in produzione: disabilitalo completamente.
PUT, DELETE, PATCH e CONNECT contano perché annunciarli invita a test. Un PUT su un percorso scrivibile può depositare file arbitrari sul server — i server WebDAV sono l'esempio classico. Un DELETE senza autenticazione può permettere a un chiamante di rimuovere risorse. Anche quando questi metodi passano attraverso la logica di autorizzazione dell'applicazione, averli nell'header Allow concentra la lista di sondaggio dell'attaccante.
Come risolverlo
Blocca TRACE a livello di server block e restituisci 405 per qualsiasi metodo fuori dalla breve lista che la tua app usa effettivamente.
server {
# Reject TRACE completely
if ($request_method = TRACE) {
return 405;
}
location / {
limit_except GET HEAD POST OPTIONS {
deny all;
}
# ... your proxy_pass or root ...
}
}In Express aggiungi un middleware che rifiuta qualsiasi metodo al di fuori della lista consentita. Nei Route Handler di Next.js, esporta solo le funzioni per i metodi che gestisci — il framework restituisce automaticamente 405 per tutto il resto.
// Express: block anything outside the allowlist early
import express from "express";
const app = express();
app.use((req, res, next) => {
const allowed = new Set(["GET", "HEAD", "POST", "OPTIONS"]);
if (!allowed.has(req.method)) {
res.set("Allow", [...allowed].join(", "));
return res.status(405).json({ error: "Method Not Allowed" });
}
next();
});
// Next.js Route Handler — only exported functions are reachable
// (no DELETE export → Next.js returns 405 automatically)
export async function GET(request: Request) {
return Response.json({ ok: true });
}
// export async function DELETE(...) — don't export this unless you need itUna volta aggiornato il server, conferma che l'header Allow non elenca più i metodi pericolosi.
curl -sI -X OPTIONS https://example.com/ | grep -i allow
# Expected: Allow: GET, HEAD, POST, OPTIONS
# If TRACE, PUT, DELETE, PATCH, or CONNECT appear, the restriction didn't land.FAQ
Se TRACE è bloccato, perché AppSafe lo segnala comunque?
AppSafe legge l'header Allow da una risposta OPTIONS — segnala ciò che il server annuncia, non ciò che esegue effettivamente. Un server può dichiarare di supportare TRACE nell'header Allow mentre blocca il metodo dietro una regola del firewall. Rimuovere TRACE dall'header Allow è la correzione corretta perché l'header stesso è il segnale che leggono gli attaccanti.
Annunciare PUT nell'header Allow significa che il mio server è vulnerabile all'upload di file?
Non necessariamente — PUT potrebbe richiedere autenticazione, essere instradato a un handler che lo rifiuta, o non fare nulla. Il rischio è che invita a test. Se la tua app non ha mai bisogno di PUT da chiamanti non autenticati, rimuovilo dalla risposta Allow.
Come lo rileva AppSafe?
AppSafe invia una richiesta HTTP OPTIONS all'URL radice del tuo sito e legge gli header Allow e Access-Control-Allow-Methods. Se appaiono TRACE, PUT, PATCH, DELETE o CONNECT, il risultato viene segnalato. TRACE è contrassegnato con severità alta; gli altri con severità media.
La tua app è interessata?
AppSafe controlla questo e decine di altri problemi in un'unica scansione gratuita.
Scansiona la mia app gratisGuide correlate
Configurazione CORS errata: le trappole del wildcard e della riflessione
Consenti ogni origine e qualsiasi sito potrà leggere la tua API.
Pagine di errore dettagliate e stack trace in produzione
Uno stack trace dice agli attaccanti esattamente dove mirare.
Introspection GraphQL pubblica: perché è un problema e come disattivarla
Una sola query restituisce l'intero schema. Disattivala in produzione.
Indici di directory aperti: quando il tuo file server elenca tutto
Un file server che elenca il proprio contenuto regala agli attaccanti un inventario gratuito.