Semua panduan
Tingkat SedangProtokol HTTP & Permintaan Sisi Server

Metode HTTP berbahaya: bagaimana TRACE, PUT, dan DELETE diiklankan

Server HTTP dapat mengiklankan metode yang mereka dukung dengan merespons permintaan OPTIONS. Ketika daftar tersebut mencakup metode berbahaya — TRACE, PUT, DELETE, PATCH, atau CONNECT — yang tidak diperlukan di produksi, Anda memberikan kepada penyerang peta titik masuk potensial. AppSafe mengirim permintaan OPTIONS ke URL root situs Anda dan menandai metode berbahaya yang ditemukan di header Allow atau Access-Control-Allow-Methods.

Apa itu

Setiap server HTTP dapat merespons permintaan OPTIONS dengan header Allow yang mendaftar metode yang diterima: GET, POST, HEAD, OPTIONS, ditambah yang lainnya yang didukung. Beberapa framework dan reverse proxy menambahkan Access-Control-Allow-Methods ke respons yang sama. Tidak ada header yang wajib, tetapi ketika ada, keduanya memberi tahu pemanggil mana saja kata kerja yang perlu dicoba.

AppSafe mengirim satu permintaan OPTIONS ke origin Anda dan memeriksa kedua header untuk metode dalam daftar bahaya singkat: TRACE, PUT, PATCH, DELETE, dan CONNECT. TRACE mendapatkan temuannya sendiri dengan tingkat keparahan tinggi; sisanya dikelompokkan bersama pada keparahan sedang. Pemeriksaan ini murni tentang iklan — metode yang tercantum di Allow mungkin atau mungkin tidak melakukan apa pun di server Anda, tetapi mencantumkannya mendorong eksplorasi.

Kenapa penting

TRACE adalah yang paling serius. Ia mengembalikan seluruh permintaan — termasuk semua header — kembali ke pemanggil. Di lingkungan di mana kredensial atau cookie sesi diteruskan sebagai header permintaan, gema ini dapat mengekspos nilai-nilai tersebut ke skrip di halaman melalui cross-site tracing (XST). Browser modern memblokir TRACE dari XHR/fetch, tetapi proxy dan load balancer mungkin tidak. TRACE tidak memiliki penggunaan produksi yang sah: matikan sepenuhnya.

PUT, DELETE, PATCH, dan CONNECT penting karena mengiklankannya mengundang pengujian. PUT yang mendarat di jalur yang dapat ditulis dapat menempatkan file arbitrer di server — server WebDAV adalah contoh klasiknya. DELETE yang tidak dijaga oleh autentikasi dapat membiarkan pemanggil menghapus resource. Bahkan ketika metode-metode ini melalui logika otorisasi aplikasi Anda dan sepenuhnya aman, memilikinya di header Allow memfokuskan daftar pemeriksaan penyerang.

Cara memperbaiki

Nonaktifkan TRACE dan batasi metode di nginx

Blokir TRACE di tingkat server block dan kembalikan 405 untuk metode apa pun di luar daftar singkat yang benar-benar digunakan aplikasi Anda.

server {
  # Reject TRACE completely
  if ($request_method = TRACE) {
    return 405;
  }

  location / {
    limit_except GET HEAD POST OPTIONS {
      deny all;
    }
    # ... your proxy_pass or root ...
  }
}
Batasi metode di Express / Next.js

Di Express tambahkan middleware yang menolak metode apa pun di luar allowlist. Di Next.js Route Handler, ekspor hanya fungsi untuk metode yang Anda tangani — framework secara otomatis mengembalikan 405 untuk yang lainnya.

// 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 it
Verifikasi dengan permintaan OPTIONS setelah perubahan

Setelah server diperbarui, konfirmasi bahwa header Allow tidak lagi mencantumkan metode berbahaya.

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

Jika TRACE diblokir, mengapa AppSafe masih menandainya?

AppSafe membaca header Allow dari respons OPTIONS — ia menandai apa yang diiklankan server, bukan apa yang benar-benar dieksekusi. Server dapat mengklaim mendukung TRACE di header Allow-nya sambil memblokir metode di belakang aturan firewall. Menghapus TRACE dari header Allow adalah perbaikan yang tepat karena header itu sendiri adalah sinyal yang dibaca penyerang.

Mengiklankan PUT di header Allow berarti server saya rentan terhadap unggahan file?

Belum tentu — PUT mungkin memerlukan autentikasi, dirutekan ke handler yang menolaknya, atau tidak melakukan apa pun sama sekali. Risikonya adalah mengundang pengujian. Jika aplikasi Anda tidak pernah memerlukan PUT dari pemanggil yang tidak diautentikasi, hapus dari respons Allow.

Bagaimana AppSafe mendeteksi ini?

AppSafe mengirim permintaan HTTP OPTIONS ke URL root situs Anda dan membaca header respons Allow dan Access-Control-Allow-Methods. Jika TRACE, PUT, PATCH, DELETE, atau CONNECT muncul, temuan dilaporkan. TRACE ditandai dengan keparahan tinggi; yang lainnya dengan keparahan sedang.

Apakah aplikasimu terpengaruh?

AppSafe memeriksa ini dan puluhan masalah lain dalam satu pemindaian gratis.

Pindai aplikasiku gratis

Panduan terkait

Kesalahan konfigurasi CORS: jebakan wildcard dan reflection

Izinkan setiap origin dan situs mana pun bisa membaca API-mu.

Halaman error verbose dan stack trace di production

Stack trace memberi tahu penyerang persis ke mana harus membidik.

Introspection GraphQL publik: mengapa ini masalah dan cara mematikannya

Satu query mengembalikan seluruh skema Anda. Matikan di production.

Indeks direktori terbuka: saat file server Anda menampilkan semuanya

File server yang menampilkan isinya memberi penyerang inventaris gratis.