Gefährliche HTTP-Methoden: wie TRACE, PUT und DELETE annonciert werden
HTTP-Server können anzeigen, welche Methoden sie unterstützen, indem sie auf eine OPTIONS-Anfrage antworten. Wenn diese Liste gefährliche Methoden enthält — TRACE, PUT, DELETE, PATCH oder CONNECT — die in der Produktion nicht benötigt werden, übergibst du Angreifern eine Karte potenzieller Einstiegspunkte. AppSafe sendet eine OPTIONS-Anfrage an deine Root-URL und markiert alle gefährlichen Methoden in den Allow- oder Access-Control-Allow-Methods-Headern.
Was es ist
Jeder HTTP-Server kann auf eine OPTIONS-Anfrage mit einem Allow-Header antworten, der die unterstützten Methoden auflistet: GET, POST, HEAD, OPTIONS und was auch immer sonst unterstützt wird. Einige Frameworks und Reverse-Proxys fügen Access-Control-Allow-Methods zur gleichen Antwort hinzu. Keiner der Header ist erforderlich, aber wenn sie vorhanden sind, zeigen sie jedem Aufrufer genau, welche Verben er ausprobieren soll.
AppSafe sendet eine OPTIONS-Anfrage an deinen Origin und überprüft beide Header auf Methoden in einer kurzen Gefahrenliste: TRACE, PUT, PATCH, DELETE und CONNECT. TRACE erhält einen eigenen Fund mit hohem Schweregrad; die übrigen werden mit mittlerem Schweregrad gruppiert. Die Prüfung dreht sich rein um Annoncierung — eine in Allow gelistete Methode kann auf deinem Server etwas tun oder nicht, aber sie aufzulisten, ermutigt zur Erkundung.
Warum es wichtig ist
TRACE ist am ernstesten. Es spiegelt die vollständige Anfrage — einschließlich aller Header — zurück an den Aufrufer. In Umgebungen, in denen Anmeldedaten oder Session-Cookies als Request-Header weitergegeben werden, könnte dieses Echo diese Werte über Cross-Site Tracing (XST) einem Skript auf der Seite zugänglich machen. Moderne Browser blockieren TRACE über XHR/fetch, aber Proxys und Load Balancer möglicherweise nicht. TRACE hat keinen legitimen Produktionseinsatz: deaktiviere es vollständig.
PUT, DELETE, PATCH und CONNECT sind relevant, weil ihre Annoncierung zum Testen einlädt. Ein PUT auf einem beschreibbaren Pfad kann beliebige Dateien auf dem Server ablegen — WebDAV-Server sind das klassische Beispiel. Ein DELETE ohne Authentifizierung kann einem Aufrufer erlauben, Ressourcen zu löschen. Selbst wenn diese Methoden durch die Autorisierungslogik deiner Anwendung gehen, konzentriert sie im Allow-Header zu haben die Probenliste eines Angreifers.
So behebst du es
Blockiere TRACE auf Server-Block-Ebene und gib 405 für jede Methode zurück, die nicht in der kurzen Liste der Methoden steht, die deine App tatsächlich verwendet.
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 füge eine Middleware hinzu, die jede Methode außerhalb der Allowlist ablehnt. In Next.js Route Handlers exportiere nur die Funktionen für die Methoden, die du behandelst — das Framework gibt automatisch 405 für alles andere zurück.
// 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 itSobald der Server aktualisiert ist, bestätige, dass der Allow-Header die gefährlichen Methoden nicht mehr auflistet.
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
Wenn TRACE blockiert ist, warum markiert AppSafe es trotzdem?
AppSafe liest den Allow-Header aus einer OPTIONS-Antwort — es markiert, was der Server ankündigt, nicht was er tatsächlich ausführt. Ein Server kann TRACE im Allow-Header beanspruchen, während die Methode hinter einer Firewall-Regel blockiert ist. TRACE aus dem Allow-Header zu entfernen ist die richtige Lösung, da der Header selbst das Signal ist, das Angreifer lesen.
Bedeutet die Annoncierung von PUT im Allow-Header, dass mein Server anfällig für Datei-Uploads ist?
Nicht unbedingt — PUT erfordert möglicherweise Authentifizierung, wird zu einem Handler geleitet, der es ablehnt, oder tut nichts. Das Risiko ist, dass es zum Testen einlädt. Wenn deine App PUT von nicht authentifizierten Aufrufern nie benötigt, entferne es aus der Allow-Antwort.
Wie erkennt AppSafe das?
AppSafe sendet eine HTTP-OPTIONS-Anfrage an die Root-URL deiner Website und liest die Allow- und Access-Control-Allow-Methods-Antwort-Header. Wenn TRACE, PUT, PATCH, DELETE oder CONNECT erscheinen, wird der Fund gemeldet. TRACE wird mit hohem Schweregrad markiert; die übrigen mit mittlerem.
Ist deine App betroffen?
AppSafe prüft dies und Dutzende weitere Probleme in einem kostenlosen Scan.
Meine App gratis scannenVerwandte Guides
CORS-Fehlkonfiguration: die Wildcard- und Reflection-Fallen
Erlaube jeden Origin und jede Website kann deine API lesen.
Ausführliche Fehlerseiten und Stack Traces in Produktion
Ein Stack Trace zeigt Angreifern genau, wohin sie zielen müssen.
Öffentliche GraphQL-Introspection: warum sie ein Problem ist und wie du sie abschaltest
Eine einzige Query liefert dein komplettes Schema. Schalte sie in Produktion ab.
Offene Verzeichnis-Indizes: wenn dein Dateiserver alles auflistet
Ein Dateiserver, der seinen Inhalt auflistet, liefert Angreifern ein kostenloses Inventar.