การรักษาความปลอดภัย API ในระบบจริง

เสริมความแข็งแกร่งให้ Node API ในระบบจริง ด้วย CORS ที่ถูกต้อง การจำกัดอัตราการเรียก เฮดเดอร์ความปลอดภัย และการป้องกันความเสี่ยงหลักตาม OWASP API

11 นาที · 3 คำถาม

OWASP ดูแลรายการ top 10 ที่อุทิศให้แก่ API โดยเฉพาะ ความเสี่ยงที่โดดเด่นสามอันดับ ได้แก่ BOLA (Broken Object Level Authorization คือการเข้าถึงอ็อบเจกต์ของผู้ใช้อื่นด้วยการเปลี่ยน id), Broken Authentication (โทเคนที่ตรวจสอบไม่ดี ความลับที่อ่อนแอ) และ Unrestricted Resource Consumption (ไม่มีการจำกัดอัตรา ขนาด หรือเวลา) สังเกตว่าไม่มีสักอันในสามอันนี้ที่แก้ได้ด้วยการติดตั้งไลบรารี พวกมันเป็นคุณสมบัติของการออกแบบของคุณ เรามาเริ่มกันที่กลไกที่ครอบคลุมทุกส่วน ได้แก่ CORS การจำกัดอัตราการเรียก และเฮดเดอร์

import { createServer } from "node:http";

const allowed = new Set(["https://app.example.com"]);

const server = createServer((req, res) => {
  const origin = req.headers.origin;
  if (origin && allowed.has(origin)) {
    res.setHeader(
      "Access-Control-Allow-Origin",
      origin,
    );
    res.setHeader("Vary", "Origin");
  }
  if (req.method === "OPTIONS") {
    res.setHeader(
      "Access-Control-Allow-Methods",
      "GET,POST,PUT,DELETE",
    );
    res.setHeader(
      "Access-Control-Allow-Headers",
      "content-type,authorization",
    );
    res.setHeader("Access-Control-Max-Age", "86400");
    res.writeHead(204).end();
    return;
  }
  res.setHeader("Content-Type", "application/json");
  res.end(JSON.stringify({ ok: true }));
});

server.listen(3000);

จงเข้าใจให้ชัดว่า CORS ไม่ใช่ อะไร นั่นคือมันไม่ใช่การป้องกันฝั่งเซิร์ฟเวอร์ curl หรือแบ็กเอนด์ของบุคคลที่สามจะเพิกเฉยต่อเฮดเดอร์เหล่านี้โดยสิ้นเชิง มีเพียงเบราว์เซอร์เท่านั้นที่บังคับใช้มัน เพื่อปกป้อง ผู้ใช้ของมัน กฎสามข้อจากผู้เชี่ยวชาญ ได้แก่ คืน origin ที่ตรงเป๊ะจาก allowlist (อย่าสะท้อนเฮดเดอร์ Origin กลับไปแบบไม่ไตร่ตรองเด็ดขาด), เพิ่ม Vary: Origin เพื่อไม่ให้แคชตัวกลางปนเปื้อน และพึงรู้ว่าไวลด์การ์ด * จะถูกเบราว์เซอร์ปฏิเสธทันทีที่คำขอพกคุกกี้มาด้วย (credentials)

const WINDOW_MS = 60_000;
const LIMIT = 100;
const hits = new Map();

function check(ip) {
  const now = Date.now();
  const entry = hits.get(ip);
  if (!entry || now - entry.start >= WINDOW_MS) {
    hits.set(ip, { start: now, count: 1 });
    return { ok: true, remaining: LIMIT - 1 };
  }
  entry.count += 1;
  const remaining = Math.max(LIMIT - entry.count, 0);
  return { ok: entry.count <= LIMIT, remaining };
}

console.log(check("203.0.113.7"));

เฮดเดอร์ความปลอดภัยใช้โค้ดเพียงไม่กี่บรรทัดแต่บล็อกการโจมตีได้ทั้งประเภท HSTS บังคับให้ใช้ HTTPS สำหรับการเข้าชมครั้งต่อไป X-Content-Type-Options: nosniff ป้องกันไม่ให้เบราว์เซอร์เดาชนิด MIME และ CSP ที่เข้มงวด (default-src 'none') จะกำจัดการนำผลตอบกลับของ API ที่ถูกเรนเดอร์ในเบราว์เซอร์โดยผิดพลาดไปใช้ประโยชน์ในทางร้าย นอกจากนี้จงลบเฮดเดอร์ใด ๆ ที่เปิดเผยสแตกของคุณ Express เพิ่ม X-Powered-By มาโดยค่าเริ่มต้น จงปิดมันด้วย app.disable('x-powered-by')

function setSecurityHeaders(res) {
  res.setHeader(
    "Strict-Transport-Security",
    "max-age=63072000; includeSubDomains",
  );
  res.setHeader("X-Content-Type-Options", "nosniff");
  res.setHeader(
    "Content-Security-Policy",
    "default-src 'none'; frame-ancestors 'none'",
  );
  res.setHeader("Cache-Control", "no-store");
}

export { setSecurityHeaders };

ทดสอบความรู้

ตรวจสอบว่าคุณจำประเด็นสำคัญของบทเรียนนี้ได้ครบถ้วน

1. จริง ๆ แล้วกลไก CORS ปกป้องอะไร?
   • เซิร์ฟเวอร์จากคำขออัตโนมัติ (curl, สคริปต์)
   • ผู้ใช้เบราว์เซอร์จากการอ่านข้ามต้นทางที่ไม่ได้รับอนุญาต
   • API จากการโจมตีแบบปฏิเสธการให้บริการ
2. เหตุใด Access-Control-Allow-Origin: * จึงเข้ากันไม่ได้กับคำขอที่ส่งคุกกี้?
   • เบราว์เซอร์ปฏิเสธการผสมนี้เพื่อเลี่ยงการเปิดเผยเซสชันที่ยืนยันตัวตนแล้วให้แก่เว็บไซต์ใด ๆ
   • เซิร์ฟเวอร์คืนข้อผิดพลาด 500 โดยอัตโนมัติ
   • ไวลด์การ์ดปิดการใช้คุกกี้ที่ฝั่งเซิร์ฟเวอร์
3. API ที่ยืนยันตัวตนแล้วคืน GET /invoices/42 ให้ผู้ใช้ที่ไม่ได้เป็นเจ้าของใบแจ้งหนี้นั้น นี่คือความเสี่ยง OWASP API ข้อใด?
   • Injection
   • Broken Object Level Authorization (BOLA)
   • Security Misconfiguration
   • Server-Side Request Forgery