Brute Force Protection and Signed URLs

Use explicit Elpod security boundaries for repeated login attempts and time-limited URL signatures in Elysia APIs.

Elpod exposes security boundaries for repeated attempts and signed links in Elysia APIs on Bun. Use them when login or temporary URL flows need explicit policies and shared state appropriate to the deployment.

The idea

Brute-force protection makes repeated guesses expensive. A signed URL does the opposite: it makes a specific temporary invitation easy to verify without storing a giant permission object in the link. Both tools need a narrow purpose and an expiry story.

How Elpod provides it

Use BruteForceGuard to track repeated failures at a login or sensitive-operation boundary. The memory store is bounded and process-local; a shared atomic store is needed across replicas.

import { BruteForceGuard, MemoryBruteForceStore, TooManyRequests } from "@elpod/core";

const guard = new BruteForceGuard({
  maxFailures: 5,
  windowMs: 15 * 60_000,
  lockoutMs: 15 * 60_000,
  store: new MemoryBruteForceStore(),
});
const decision = await guard.check(`login:${normalizedEmail}`);
if (!decision.allowed) throw TooManyRequests("Try again later");

Record failures only after a real verification failure, clear state after successful authentication according to your policy, and avoid exposing whether an account exists.

Signed URLs provide an integrity and expiry boundary for links such as downloads:

import { createSignedUrl, verifySignedUrl } from "@elpod/core";

const url = await createSignedUrl("https://example.test/download", secret, {
  expiresAt: Date.now() + 60_000,
});
const verified = await verifySignedUrl(url, secret);

Common mistakes

Keying lockout only by email or only by IP.
Creating signed URLs with secrets in query parameters.
Treating a valid signature as authorization to every resource.
Using server-local time without clock discipline across instances.

Production notes

Use a shared store for lockout state, protect signing keys, set short expiries, include resource and tenant context in the signed material, and authorize the resource after verification. Signed URLs do not encrypt data or revoke a link before expiry.

Authentication · Rate limiting · Security overview.