Rate limit & penyalahgunaan akun

Portal berlangganan punya dua musuh: skrip yang mencoba ribuan sandi, dan satu akun yang dipakai tiga puluh orang. Keduanya butuh pertahanan yang berbeda.

Dua lapis, dua tugas

Keduanya dibutuhkan. Cloudflare tidak tahu email mana yang sedang dicoba; aplikasimu tidak ingin menghabiskan kapasitas untuk membaca request yang jelas-jelas serangan.

Kunci yang benar untuk login

Kunci per IP saja      → penyerang dengan botnet melewatinya
Kunci per email saja   → penyerang mengunci akun orang lain (denial of service)
Kunci KEDUANYA         → benar

// src/lib/batas.ts
import { redis } from "./redis";

export async function bolehCoba(ip: string, email: string): Promise<boolean> {
  const kunci = [`login:ip:${hashIp(ip)}`, `login:email:${sha256(email)}`];
  const batas = [20, 5];              // per IP longgar, per email ketat
  const jendela = 15 * 60;

  for (let i = 0; i < kunci.length; i++) {
    const n = await redis.incr(kunci[i]!);
    if (n === 1) await redis.expire(kunci[i]!, jendela);
    if (n > batas[i]!) return false;
  }
  return true;
}

Kenapa harus Redis, bukan Map

Batas: 5 percobaan
Task ECS: 12

Penyerang mencoba 60 kali. ALB menyebarkannya rata:
  tiap task melihat 5 percobaan → tidak ada yang melewati batas
  penyerang sebenarnya mencoba 60 kali.

Pembatas hanya berarti kalau hitungannya dibagi. Ini salah satu dari sedikit hal di roadmap ini yang benar-benar mewajibkan Redis — bukan sekadar mempercepat.

Alternatif tanpa Redis: tabel MySQL

CREATE TABLE percobaan (
  kunci    VARCHAR(64) NOT NULL,
  jendela  INT UNSIGNED NOT NULL,     -- unix time dibagi ukuran jendela
  jumlah   INT UNSIGNED NOT NULL DEFAULT 0,
  PRIMARY KEY (kunci, jendela)
) ENGINE=InnoDB;

const jendela = Math.floor(Date.now() / 1000 / 900);   // 15 menit

await dbTulis
  .insertInto("percobaan")
  .values({ kunci, jendela, jumlah: 1 })
  .onDuplicateKeyUpdate((eb) => ({ jumlah: eb("percobaan.jumlah", "+", 1) }))
  .execute();

Lebih lambat dari Redis dan menambah tulisan ke database, tapi bekerja dan tidak menambah komponen baru untuk dioperasikan. Untuk jalur yang jarang seperti login, ini pilihan yang masuk akal. Jangan pakai untuk jalur baca bervolume tinggi.

Selalu kirim Retry-After

return new Response(
  JSON.stringify({ error: "Terlalu banyak permintaan" }),
  {
    status: 429,
    headers: {
      "Content-Type": "application/json",
      "Retry-After": "900",
      "Cache-Control": "no-store",
    },
  },
);

Cache-Control: no-store pada respons 429 itu penting: kamu tidak ingin Cloudflare meng-cache penolakan dan menyajikannya ke pembaca lain yang kebetulan berbagi jalur yang sama.

Aturan Cloudflare yang layak dipasang

Berbagi akun: kebocoran pendapatan yang sesungguhnya

-- Akun dengan sesi aktif dari banyak jaringan berbeda
SELECT
  s.member_id,
  m.email,
  COUNT(*)                      AS sesi_aktif,
  COUNT(DISTINCT s.ip)          AS ip_berbeda,
  COUNT(DISTINCT s.peramban)    AS peramban_berbeda
FROM sesi s
JOIN member m ON m.id = s.member_id
WHERE s.kedaluwarsa > NOW()
  AND s.dipakai_pada > DATE_SUB(NOW(), INTERVAL 7 DAY)
GROUP BY s.member_id, m.email
HAVING ip_berbeda > 8 OR sesi_aktif > 12
ORDER BY ip_berbeda DESC
LIMIT 50;

Cara paling lembut menegakkannya: batasi jumlah sesi aktif. Saat sesi ke-enam dibuat, sesi tertua dihapus. Pemilik akun yang wajar tidak pernah menyadarinya; yang membagikan sandinya ke dua puluh orang akan menemukan bahwa mereka saling mengeluarkan — dan itu memaksa percakapan tanpa kamu perlu menuduh siapa pun.

const MAKS_SESI = 5;

// setelah membuat sesi baru
await dbTulis
  .deleteFrom("sesi")
  .where("member_id", "=", memberId)
  .where("id", "not in", (eb) =>
    eb.selectFrom("sesi")
      .select("id")
      .where("member_id", "=", memberId)
      .orderBy("dipakai_pada", "desc")
      .limit(MAKS_SESI),
  )
  .execute();

Scraping isi berbayar