Coder Legion - Recent posts tagged web-security

Enterprise Cloud WAF vs Self-Hosted: A Cost-and-Control Breakdown

Sat, 10 Oct 2026 20:30:22 +0000

Enterprise Cloud WAF vs Self-Hosted: A Cost-and-Control Breakdown

When a larger organization evaluates a WAF, the conversation quickly moves past "does it block attacks?" to "who controls it, and what does it cost?" Here's how an enterprise cloud WAF compares to a self-hosted one on those two axes.

Control

A self-hosted WAF (like SafeLine) puts configuration in your hands. You set the rules, you see the raw traffic, and the data stays on your infrastructure. For teams with strict data-residency or compliance needs, that control is the whole point.

An enterprise cloud WAF (like Imperva) centralizes control with the vendor. You get a polished console and bundled services (CDN, DDoS, bot management), but you operate within their model and route traffic through their edge.

Cost

Self-hosted: the Community Edition is free for up to 10 apps at 800 QPS. Larger needs use paid tiers, but there's no per-seat or per-property enterprise premium.
Enterprise cloud: priced as a subscription sized to your traffic and feature set, typically with a contract and onboarding.

For a handful of sites, self-hosted is effectively free to start. For a global estate with compliance and SLA requirements, the managed platform's bundled services can justify the spend.

Where each fits

	Self-hosted	Enterprise cloud
Best for	Small teams, cost-sensitive, control-focused	Large orgs, compliance, SLA needs
Cost model	Free tier + optional paid tiers	Enterprise subscription
Data	On your servers	Through vendor edge
Extras	Dashboard, stats	CDN, DDoS, bot mgmt

Getting started self-hosted

If you want to see the control model for yourself, install SafeLine on a server you already have:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Open https://<your-server-ip>:9443, point it at your app, and your traffic is filtered — no contract, no DNS change.

FAQ

Is self-hosted "enterprise-grade"?

The detection engine is production-grade semantic analysis with low false positives, used at scale. The free tier is sized for ~10 apps; paid tiers cover more.

Do I lose the CDN with self-hosted?

A self-hosted WAF focuses on the application layer. Pair it with whatever CDN you already use.

Which is faster to deploy?

Self-hosted: one command and a console. Enterprise cloud: onboarding plus routing setup.

Ready to give SafeLine a try?

Appliance WAF vs Container WAF: The Deployment Trade-off

Sat, 10 Oct 2026 10:27:41 +0000

Appliance WAF vs Container WAF: The Deployment Trade-off

Not all WAFs deploy the same way. Some ship as dedicated hardware or virtual appliances; others run as a lightweight container on a server you already own. The difference changes your cost, your footprint, and how fast you can get protected.

The appliance model

An appliance-based WAF (like Barracuda WAF) is typically delivered as a hardware box, a virtual appliance, or a cloud instance. It's often purchased with a support contract and managed through the vendor's console. The upside is vendor backing; the downside is heavier provisioning and dedicated resources.

The container model

A container-based WAF (like SafeLine) runs as a reverse proxy on your existing server. One install command, and it's filtering traffic. No dedicated hardware, no separate instance to babysit.

Comparing the trade-offs

	Appliance WAF	Container WAF
Provisioning	Hardware/virtual appliance + setup	One container on existing server
Footprint	Dedicated resources	Lightweight, shared host
Support model	Vendor contract	Community + paid tiers
Cost	License + often support	Free Community Edition; paid tiers
Time to protect	Longer	Minutes

Which should you choose?

If your environment mandates an approved appliance with vendor SLAs, that's a procurement decision a container WAF doesn't aim to replace. For most teams, a container WAF is enough and dramatically cheaper to run.

Spin up SafeLine on a server you already have:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Open https://<your-server-ip>:9443, point it at your app, and your traffic is filtered — no appliance to provision.

FAQ

Does SafeLine need dedicated hardware?

No. It runs as a container on a server you already operate.

Can a container WAF block the same attacks as an appliance?

For application-layer threats (SQLi, XSS, bots), yes — both filter HTTP traffic; the delivery model is what differs.

Which is faster to deploy?

Container: one command and a console. Appliance: provisioning plus configuration.

Ready to give SafeLine a try?

Appliance WAF vs Container WAF: The Deployment Trade-off

Sat, 10 Oct 2026 06:09:10 +0000

Appliance WAF vs Container WAF: The Deployment Trade-off

The appliance model

The container model

A container-based WAF (like SafeLine) runs as a reverse proxy on your existing server. One install command, and it's filtering traffic. No dedicated hardware, no separate instance to babysit.

Comparing the trade-offs

	Appliance WAF	Container WAF
Provisioning	Hardware/virtual appliance + setup	One container on existing server
Footprint	Dedicated resources	Lightweight, shared host
Support model	Vendor contract	Community + paid tiers
Cost	License + often support	Free Community Edition; paid tiers
Time to protect	Longer	Minutes

Which should you choose?

Spin up SafeLine on a server you already have:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Open https://<your-server-ip>:9443, point it at your app, and your traffic is filtered — no appliance to provision.

FAQ

Does SafeLine need dedicated hardware?

No. It runs as a container on a server you already operate.

Can a container WAF block the same attacks as an appliance?

For application-layer threats (SQLi, XSS, bots), yes — both filter HTTP traffic; the delivery model is what differs.

Which is faster to deploy?

Container: one command and a console. Appliance: provisioning plus configuration.

Ready to give SafeLine a try?

Enterprise Cloud WAF vs Self-Hosted: A Cost-and-Control Breakdown

Sat, 10 Oct 2026 06:08:23 +0000

Enterprise Cloud WAF vs Self-Hosted: A Cost-and-Control Breakdown

Control

Cost

Self-hosted: the Community Edition is free for up to 10 apps at 800 QPS. Larger needs use paid tiers, but there's no per-seat or per-property enterprise premium.
Enterprise cloud: priced as a subscription sized to your traffic and feature set, typically with a contract and onboarding.

For a handful of sites, self-hosted is effectively free to start. For a global estate with compliance and SLA requirements, the managed platform's bundled services can justify the spend.

Where each fits

	Self-hosted	Enterprise cloud
Best for	Small teams, cost-sensitive, control-focused	Large orgs, compliance, SLA needs
Cost model	Free tier + optional paid tiers	Enterprise subscription
Data	On your servers	Through vendor edge
Extras	Dashboard, stats	CDN, DDoS, bot mgmt

Getting started self-hosted

If you want to see the control model for yourself, install SafeLine on a server you already have:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Open https://<your-server-ip>:9443, point it at your app, and your traffic is filtered — no contract, no DNS change.

FAQ

Is self-hosted "enterprise-grade"?

The detection engine is production-grade semantic analysis with low false positives, used at scale. The free tier is sized for ~10 apps; paid tiers cover more.

Do I lose the CDN with self-hosted?

A self-hosted WAF focuses on the application layer. Pair it with whatever CDN you already use.

Which is faster to deploy?

Self-hosted: one command and a console. Enterprise cloud: onboarding plus routing setup.

Ready to give SafeLine a try?

WAF 101: What Actually Happens When a Request Hits Your Firewall

Sat, 10 Oct 2026 04:24:57 +0000

WAF 101: What Actually Happens When a Request Hits Your Firewall

You've been told a WAF sits in front of your app and blocks bad traffic. But what actually happens, step by step, when a single HTTP request arrives? Here's the lifecycle — no marketing, just the mechanics.

1. The request hits the proxy

A WAF runs as a reverse proxy. Every request to your app lands at the WAF first, not your application. The WAF is the gatekeeper; your app only ever sees what the gatekeeper lets through.

2. It parses the request

The WAF reads the pieces that matter: the URL, the headers, the cookies, and the request body. A network firewall only looks at IPs and ports; a WAF understands HTTP, so it can see the content of the request.

3. It makes a decision

For each request, the WAF decides allow, block, or challenge:

Allow — looks like a normal request, forward to your app.
Block — matches an attack pattern (SQL injection, XSS payload, malicious bot), drop it.
Challenge — suspicious but not certain, e.g., a CAPTCHA or JavaScript check.

4. Two ways it detects attacks

Signature-based: matches known attack strings, like an antivirus. Needs constant updating, and novel attacks slip through.
Semantic analysis: understands what the request is trying to do (for example, "this is a SQL command"), so it catches variants without a signature. SafeLine uses this approach, which keeps false positives low.

5. Clean traffic moves on

Anything the WAF allows is forwarded to your application. Anything blocked never reaches your code — so the attack surface your app has to defend shrinks to near zero.

Why placement matters

A self-hosted WAF like SafeLine runs on your own server as a reverse proxy. Install it with one command:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Then open https://<your-server-ip>:9443, point it at your app, and every request flows through the gatekeeper first — no third party in the path.

FAQ

Does a WAF replace my network firewall?

No. They handle different layers. The network firewall governs connections; the WAF understands HTTP.

Will it slow my site?

A well-tuned WAF adds minimal latency. SafeLine's free tier handles 800 QPS per instance.

Is a WAF enough on its own?

It covers the application layer. Pair it with patching, rate limiting, and (if needed) a CDN for broader coverage.

Ready to protect your sites without paying for a cloud WAF?

Self-Hosted vs Managed WAF: Which Deployment Fits Your Team?

Sat, 10 Oct 2026 03:59:58 +0000

Self-Hosted vs Managed WAF: Which Deployment Fits Your Team?

Picking a WAF usually comes down to one question: do you want to run the security infrastructure yourself, or pay someone to run it for you? That single decision shapes your cost, your control, and how much operational work lands on your plate.

Two deployment models

Self-hosted (e.g., SafeLine). You install the WAF on your own server — one command — and it runs as a reverse proxy in front of your app. Your traffic never leaves your network, and you decide the config.

Managed cloud (e.g., Sucuri). The vendor runs the WAF in their own network. You point your DNS at them, and they filter traffic before it reaches you. Someone else operates the infrastructure.

What you actually give up or keep

	Self-hosted	Managed cloud
Where traffic flows	Your server only	Through the vendor's cloud
Upfront cost	Free tier available	Recurring subscription
Operational work	You patch and monitor	Vendor handles uptime
Control over config	Full	Limited to their console
Data residency	Stays with you	On the vendor's servers

How to decide

Choose self-hosted if you want predictable cost, full control, and to keep request data on your own infrastructure. SafeLine's free Community Edition covers up to 10 apps at 800 QPS and installs in one line:
```
bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en
```
Then open https://<your-server-ip>:9443 and point it at your app. No DNS change required.
Choose managed cloud if you'd rather offload operations entirely and you also want extras like malware cleanup and a CDN bundled in. The trade-off is a monthly fee and routing traffic through a third party.

The bottom line

Neither is "better" in the abstract — they optimize for different things. Self-hosted wins on cost and control; managed wins on convenience. If you're a small team that wants strong protection without a sales call, starting self-hosted is usually the faster, cheaper path.

Ready to protect your sites without paying for a cloud WAF?

What Is Authentication? A Beginner's Guide (2026)

Tue, 01 Sep 2026 05:07:56 +0000

Every time you type your email and password into a login form, something is quietly deciding whether you actually get in. That decision — proving you are who you say you are — is called authentication, and it's one of those concepts every developer touches constantly but rarely stops to explain from scratch.

If you've ever wondered what actually happens between "click Sign In" and "welcome back," or mixed up authentication with authorization in an interview, this guide is for you. By the end, you'll know exactly what authentication is, how the major methods work under the hood, and how to build a basic authentication flow yourself.

What Is Authentication? (Quick Answer)

Authentication is the process of verifying that someone is who they claim to be. It answers one question: "Who are you?" This usually happens by checking a password, a code from your phone, a fingerprint, or a token — something only the real user should have or know.

Authentication is different from authorization, which answers a separate question: "What are you allowed to do?" A logged-in user is authenticated. Whether that user can delete another person's account is authorization. Mixing these two up is one of the most common beginner mistakes — keep them mentally separate from the start.

💡 Simple way to remember it: Authentication = ID check at the door. Authorization = the guest list that decides which rooms you can enter once you're inside.

Why Authentication Matters

Without proper authentication and authorization, an app that stores personal data could expose private information to unauthorized users. Authentication provides the identity context that many authorization, personalization, and auditing systems rely on.

It matters for a few concrete reasons:

Privacy — only the right person sees their own data
Security — prevents account takeover and unauthorized access
Personalization — apps can remember who you are across visits
Accountability — actions can be traced back to a real identity (important for admin tools, financial apps, audit logs)

Authentication vs. Authorization: The Difference That Trips Everyone Up

	Authentication	Authorization
Question it answers	Who are you?	What can you do?
Happens	First	After authentication
Example	Logging in with a password	Only admins can access `/admin`
Failure result	401 Unauthorized	403 Forbidden

Why the HTTP status codes are confusingly named: 401 Unauthorized actually means "you're not authenticated" (log in first), while 403 Forbidden means "you're authenticated, but not allowed to do this." Yes, 401 should really be called "Unauthenticated" — it's a long-standing naming quirk in the HTTP spec that trips up almost every developer at least once.

Related: Role-Based Access Control (RBAC) in Next.js 16 goes deep on the authorization half of this once you're ready for it.

How Authentication Works (Step by Step)

At a high level, almost every authentication system follows the same basic loop:

The user provides credentials — a password, a fingerprint, a one-time code, or an existing account from another provider (like signing in with Google)
The server verifies those credentials — checking a hashed password, validating a signed token, or confirming a biometric match
The server issues proof of identity — usually a session or a token, stored in a cookie or sent back to the client
That proof is sent with future requests — so the user doesn't have to log in again on every page

User submits credentials
        ↓
Server verifies credentials
        ↓
Server issues session/token
        ↓
Client stores it (cookie)
        ↓
Future requests include it
        ↓
Server verifies it's still valid

That last step — verifying the proof of identity on every request — is what keeps a user "logged in" without asking for their password on every single page.

The Main Types of Authentication

There isn't just one way to authenticate someone. Here are the methods you'll actually run into as a developer.

1. Password-Based Authentication

The classic: a username/email plus a password, checked against a hashed value stored in your database. Never store plain-text passwords — always hash them with a slow, password-specific hashing algorithm such as Argon2id. If it's not available, bcrypt or another appropriate password hashing algorithm can be used.

// lib/auth/hash-password.ts
import bcrypt from "bcryptjs";

const SALT_ROUNDS = 12;

export async function hashPassword(plainPassword: string): Promise<string> {
  return bcrypt.hash(plainPassword, SALT_ROUNDS);
}

export async function verifyPassword(
  plainPassword: string,
  hashedPassword: string
): Promise<boolean> {
  return bcrypt.compare(plainPassword, hashedPassword);
}

What's happening here: bcrypt.hash() doesn't just scramble the password — it applies a slow, computationally expensive algorithm on purpose, which increases the cost of each password guess and makes large-scale brute-force attacks significantly more expensive. SALT_ROUNDS = 12 is above OWASP's minimum bcrypt work factor of 10, but the right value depends on your server's hardware and traffic. Benchmark your production environment and choose a cost that makes password verification sufficiently expensive without creating unacceptable latency.

⚠️ bcrypt limitation: bcrypt has a hard 72-byte input limit, and most implementations (including bcryptjs) silently truncate anything past it rather than erroring. Because UTF-8 characters like emoji or accented letters can take up to 4 bytes each, a password that looks well under the limit in characters can still get silently cut short in bytes — which can cause two different passwords to be treated as equivalent after truncation.
OWASP currently recommends enforcing a maximum of 72 bytes (or less, depending on the implementation) when bcrypt is used. Because UTF-8 characters can occupy multiple bytes, a character-count limit alone doesn't necessarily correspond to bcrypt's byte limit.

⚠️ Common Mistake: Comparing passwords with a plain === check after "encrypting" them with something reversible like Base64. That's encoding, not hashing — it can be reversed instantly. Only use a dedicated password-hashing library.

2. Session-Based Authentication

After a successful login, the server creates a session record stored in server-side session storage such as a database or shared cache — and gives the browser a random session ID in an httpOnly cookie. On every request, the server looks up that ID to know who's logged in.

// lib/auth/session.ts
import { cookies } from "next/headers";
import { randomUUID } from "crypto";

export async function createSession(userId: string, expiresAt: Date) {
  // Generate a random, unguessable session ID — never store the raw
  // userId (or anything else predictable) directly as the cookie's
  // value. The cookie is a reference you look up server-side; it
  // should never double as proof of identity on its own.
  const sessionId = randomUUID();

  // Persist the mapping server-side, e.g.:
  // await db.session.create({ data: { sessionId, userId, expiresAt } });

  const cookieStore = await cookies();

  cookieStore.set("session_id", sessionId, {
    httpOnly: true,
    secure: true,
    sameSite: "lax",
    expires: expiresAt,
    path: "/",
  });
}

Why each flag matters: httpOnly stops client-side JavaScript from reading the cookie (blocking a common XSS attack path). secure means it's only sent over HTTPS. sameSite: "lax" limits when the browser sends the cookie in cross-site requests and provides some CSRF protection. For state-changing operations, you should still implement an appropriate CSRF defense rather than relying on SameSite alone.

Pros: straightforward server-side revocation; deleting a session record can invalidate that session immediately, and deleting all of a user's sessions can log them out everywhere.
Cons: can require a server-side session lookup on authenticated requests, although caching can reduce the cost.

3. Token-Based Authentication (JWT)

Instead of looking anything up server-side, a JSON Web Token (JWT) packs the user's identity directly into a signed token. In a stateless JWT design, the server can verify the token cryptographically without looking up a session record in the database.

// lib/auth/jwt.ts
import { SignJWT, jwtVerify } from "jose";

const secretKey = new TextEncoder().encode(process.env.AUTH_SECRET);

export async function signToken(userId: string, expiresAt: Date) {
  return new SignJWT({})
    .setProtectedHeader({ alg: "HS256" })
    .setSubject(userId)
    .setIssuedAt()
    .setExpirationTime(expiresAt)
    .sign(secretKey);
}

export async function verifyToken(token: string) {
  try {
    const { payload } = await jwtVerify(token, secretKey, {
      algorithms: ["HS256"],
    });
    return payload;
  } catch {
    return null; // invalid or expired
  }
}

What's happening here: jose is the standard, actively maintained library for signing and verifying JWTs using the Web Crypto API — it works in Node.js, edge runtimes, and browsers. setSubject(userId) stores the user's ID in the token's standard sub claim. jwtVerify() automatically rejects the token if the signature doesn't match or if it's expired, so you never write manual expiry checks.

⚠️ Signing is not encryption. A JWT's payload is only base64url-encoded, not encrypted — anyone can decode and read it. The signature only proves it wasn't tampered with. Never put sensitive data (passwords, secrets) inside a JWT payload.

Pros: no database lookup needed to verify identity, works well across distributed/stateless servers.
Cons: harder to instantly revoke a single token before it expires (it's valid until it naturally expires unless you build extra machinery around it).

💡 For a deeper side-by-side of these two models — including how each behaves at scale — see Session vs JWT: Which Should You Use in Next.js 16?

OAuth 2.0 is an authorization framework that lets an application obtain limited access to resources on behalf of a user. It doesn't, by itself, define how an application verifies the user's identity.

For "Sign in with Google," "Sign in with Microsoft," and similar login flows, applications commonly use OpenID Connect (OIDC) — an identity layer built on top of OAuth 2.0. The identity provider authenticates the user and returns an ID token containing claims about that authentication.

User clicks "Sign in with GitHub"
        ↓
Redirected to GitHub
        ↓
User authenticates and approves access
        ↓
GitHub redirects back with a code
        ↓
Your server exchanges the code for tokens
        ↓
Your server validates the OIDC identity information
        ↓
Your app creates its own session

This is why OAuth is so popular for beginners and production apps alike — you outsource the hardest parts (password storage, breach risk, 2FA) to a provider that already does it well.

5. Multi-Factor Authentication (MFA / 2FA)

MFA requires more than one proof of identity — typically "something you know" (a password) plus "something you have" (a phone, an authenticator app code, a hardware key). Even if a password leaks, the attacker still can't get in without the second factor.

6. Passwordless Authentication (Magic Links & Passkeys)

Two increasingly common alternatives to passwords:

Magic links — the user enters their email, gets a one-time sign-in link, and clicking it logs them in. No password to remember or leak.
Passkeys (WebAuthn) — device-based authentication using Face ID, Windows Hello, or a hardware security key. No shared secret exists to steal in the first place, which makes passkeys resistant to phishing in a way passwords fundamentally aren't.

A Minimal Authentication Flow in Next.js

Here's a simplified but realistic login flow using Next.js 16, TypeScript, and session cookies — the same core pattern used by most production apps, just without the database wiring.

// actions/login.ts
"use server";

import { redirect } from "next/navigation";
import { verifyPassword } from "@/lib/auth/hash-password";
import { createSession } from "@/lib/auth/session";
import { z } from "zod";

const loginSchema = z.object({
  email: z.email(),
  password: z.string().min(8),
});

export async function login(prevState: unknown, formData: FormData) {
  const parsed = loginSchema.safeParse({
    email: formData.get("email"),
    password: formData.get("password"),
  });

  if (!parsed.success) {
    return { error: "Enter a valid email and password." };
  }

  // Look up the user in your database (pseudocode)
  const user = await db.user.findUnique({ where: { email: parsed.data.email } });

  if (!user || !(await verifyPassword(parsed.data.password, user.passwordHash))) {
    // Same generic error for both cases — don't reveal which one was wrong
    return { error: "Invalid email or password." };
  }

  const expiresAt = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000); // 7 days
  await createSession(user.id, expiresAt);

  redirect("/dashboard");
}

What's happening here: the form data is validated with Zod before touching the database — never trust raw input. Notice the login failure returns the same generic message whether the email doesn't exist or the password is wrong; revealing which one failed makes it easier for attackers to enumerate valid accounts. A working session gets created only after the password check succeeds, then the user is redirected.

⚠️ Common Mistake: Checking authentication only in proxy and assuming that's enough. Proxy-level checks are a good UX shortcut (fast redirect before a page even loads), but sensitive Server Actions, Route Handlers, and data-access functions should independently verify authentication and authorization rather than relying solely on proxy.ts.

Building this by hand is a great way to learn, but most production apps reach for a maintained library instead — see How to Add Auth.js (NextAuth v5) in Next.js 16, Add Clerk Authentication to Next.js 16, or (if you're already on Supabase) Supabase Auth vs Firebase Auth.

Common Authentication Mistakes to Avoid

Storing plain-text passwords — always hash with Argon2id or bcrypt, never store or log the raw password
Storing a predictable value as the session cookie — the cookie should be a random, unguessable reference, never the raw user ID or anything else an attacker could construct
Weak or reused session/JWT secrets — generate a long, random secret and never commit it to git
Revealing which field was wrong — "Invalid email" vs. "Invalid password" tells attackers an account exists
Skipping rate limiting — without it, attackers can brute-force passwords with unlimited attempts
Relying only on client-side checks — a hidden button or disabled form field doesn't stop a direct API request
Forgetting to expire sessions/tokens — every session and token should have a sane expiry, not live forever

Frequently Asked Questions

What is the difference between authentication and authorization?

Authentication confirms who someone is (logging in). Authorization decides what they're allowed to do once they're recognized (permissions, roles, access control). You always need authentication before authorization can happen.

Yes — a login system is simply the implementation of authentication. Whatever mechanism confirms a user's identity (password, OAuth, passkey) is functioning as authentication, regardless of what you call the feature.

What's the difference between sessions and JWTs?

A session stores authentication/session state on the server and gives the browser only a random reference ID, which allows instant revocation. A JWT stores the identity data directly inside a signed token the server can verify without a database lookup, trading easy revocation for less server-side state.

Keep JWT minimal — a JWT should not be treated as a general-purpose user profile or database replacement.

Do I need a library to build authentication, or can I build it myself?

You can build basic password + session authentication yourself using the patterns above, but for anything production-facing, an established library (Auth.js, Clerk, Better Auth, or your database provider's built-in auth) is strongly recommended — they handle edge cases like token rotation, breach detection, and secure defaults that are easy to get subtly wrong by hand.

Is two-factor authentication (2FA) actually necessary?

For anything holding sensitive data — financial info, personal messages, admin access — yes. 2FA dramatically reduces account takeover risk even when a password leaks, since the attacker also needs the second factor.

Are passkeys better than passwords?

Generally yes, from a security standpoint — passkeys are phishing-resistant because there's no shared secret to trick someone into revealing. Adoption is still growing, though, so most apps currently offer passkeys as an option alongside passwords rather than a full replacement.

Wrapping Up

Authentication boils down to one question — "who are you?" — answered through a password, a token, a device, or some combination of them. Once you separate authentication from authorization, the ecosystem becomes easier to understand: passwords and passkeys are authentication mechanisms, sessions and JWTs are ways to maintain authenticated state, and OAuth/OIDC provide delegated authorization and federated identity.

If you're building this in a real Next.js app, the next logical steps are wiring up role-based authorization on top of your authentication layer, and deciding between session-based and JWT-based auth based on whether instant revocation matters for your product.

Continue Learning

Free Developer Tools

Zod Schema Generator — generate a validated schema for your role/permission payloads straight from a JSON sample or TypeScript interface, including a ready-to-use Server Action.
Supabase RLS Policy Generator — pair this guide's application-level RBAC with database-level Row Level Security. Generates owner-only, team, and admin-override policies with the auth.uid() performance wrapper built in.

How a Dead Polyfill.io Link Got My Entire GitHub Pages Domain Flagged as Dangerous

Wed, 26 Aug 2026 04:47:00 +0000

I recently published a digital anthology project at nevmenandr.github.io/WLA.
The setup was smooth – I used Obsidian with the excellent
obsidian-publish-mkdocs plugin to generate a clean, documentation‑style site.

Everything worked beautifully… until Google Chrome started showing a bright red warning:
"Deceptive site ahead" – not just for my new project, but for every site hosted under my nevmenandr.github.io domain.

The Culprit: A Single, Innocent‑Looking Script Tag

While inspecting the generated HTML, I noticed lines where the polyfill.io link caught my eye. I tried visiting it directly (the full URL with /v3/polyfill.min.js?features=es6 on the polyfill.io domain).
Result: 401 Authorization Required – a dead service.

A Critical Red Flag: The Repository Is Stale

Digging deeper, I realised that the obsidian-publish-mkdocs repository on GitHub has not been updated for over two years.

This is a classic warning sign:

The plugin still bundles legacy dependencies that were once free but have since changed hands.
The maintainer hasn't patched or removed deprecated resources.
No security audits or dependency refreshes have occurred in that time.

While the tool works brilliantly out‑of‑the‑box, it's effectively unmaintained – and that's a risk you inherit as a user.

Why This Triggered Google's Safe Browsing

polyfill.io used to be a free, trusted CDN. But the domain was sold to a new owner who now requires payment and returns 401 (or even malicious redirects) for unauthenticated requests.

Google's crawler saw that my site included a script from a domain that now behaves suspiciously – and flagged the entire nevmenandr.github.io origin as a potential threat. This is a domain‑level penalty, meaning all my other GitHub Pages projects were blocked too.

The Fix: Step‑by‑Step Recovery Guide

If you ever face this, here's the exact process that got my site back online within ~24 hours.

1. Remove the Offending Resource

Locate and delete the problematic script tag from your HTML template.
In my case, I disabled the polyfill inclusion in the MkDocs theme config (or simply removed the line from the generated index.html).
Rebuild and redeploy your site to GitHub Pages.

2. Verify the Site is Clean

Visit your URL in a private/incognito window to confirm the red warning still appears (it will, until Google re‑crawls).
Use the Google Transparency Report tool (search for "Google Transparency Report" and then enter your domain in the Safe Browsing section) to check your domain's current status.

3. Claim Ownership in Google Search Console

Go to Google Search Console (search for it – it's Google's official tool for webmasters).
Add your site as a property (use the URL‑prefix type, e.g., https://nevmenandr.github.io/WLA/).
Verify ownership using the recommended method – for GitHub Pages, the easiest is:
1. Download the HTML verification file from Search Console.
2. Add it to the root of your repository (/path/to/your/repo/).
3. Commit and push – GitHub Pages will serve it automatically.

4. Request a Review

In Search Console, navigate to Security & Manual Actions → Security Issues.
If the warning is still active, you'll see a "Request Review" button.
In the review form:
- Explain clearly that you've removed the external resource that caused the issue.
- Mention that you've scanned your site for any other suspicious content.
- If you use any other external scripts, list them and confirm they are safe.

5. Wait (Usually 24‑48 Hours)

Google's team will review your request. In my case, the domain was cleared in about 24 hours.
You can monitor the status in Search Console – it will change from "Pending" to "Approved" or "Rejected".

Key Lessons for Developers

Third‑party scripts are liabilities. Always audit CDN links – especially free ones that can change ownership or monetisation models overnight.
Consider self‑hosting critical libraries or using well‑established CDNs with clear SLAs (e.g., cdnjs, jsdelivr).
Check the maintenance status of your tools.
A plugin that hasn't seen a commit in two years is a ticking time bomb. Always review the last update date before relying on any open‑source dependency in production. If it's stale, fork it, update the dependencies yourself, or look for an actively maintained alternative.
Google Safe Browsing penalises at the domain level.
A single compromised resource can take down all your sub‑projects, including unrelated ones. This is particularly painful on GitHub Pages where you share the *.github.io namespace.

Automate dependency checks.
Add a step in your CI/CD pipeline to test external URLs for HTTP 2xx responses. For example, with a simple curl check:

if ! curl -s -o /dev/null -w "%{http_code}" https://polyfill.io/v3/polyfill.min.js | grep -q "200"; then
  echo "⚠️  Polyfill.io is unreachable – aborting build"
  exit 1
fi

Know the recovery path.
Having a verified Google Search Console property is not optional if you publish public sites. It's your only channel to communicate with Google's security team when false positives occur.
Don't panic – the process works.
The warning looked scary, but the fix was straightforward. The key is to act quickly, be transparent in your review request, and double‑check that no other deprecated services remain.

Final Thought

Open‑source tools like obsidian-publish-mkdocs are brilliant for productivity – but they often bundle legacy dependencies for maximum compatibility, and when a repository stagnates for years, those dependencies can rot. As developers, it's our responsibility to review every external asset and check the pulse of our toolchain before going live.

One dead polyfill link and an unmaintained plugin cost me a day of heartache. Don't let it happen to you. 🚀

How I Designed an Anti-Proxy Attendance System Using Dynamic QR Authentication

Fri, 17 Jul 2026 16:39:51 +0000

"Anyone can generate a QR code. Designing one that actually prevents misuse is the hard part."

When people hear "QR-based attendance," the first question is usually:

"Can't someone just take a photo of the QR code and send it to their friend?"

The answer is: yes, if the system is designed poorly.

That question became one of the biggest engineering challenges while building my attendance platform.

Instead of thinking about QR codes as images, I started thinking about them as temporary authentication tokens.

The Problem
Most QR attendance systems work like this:

Teacher generates a QR code.
Students scan it.
Attendance is marked.
Simple.

Unfortunately, it's also vulnerable.

A student can:

Photograph the QR code.
Send it through WhatsApp.
Another student scans it from somewhere else.
Attendance gets recorded.
The QR code itself becomes the vulnerability.

Rethinking the QR Code
Instead of creating a QR code that simply points to an attendance page, I designed it to behave more like a short-lived authentication token.

Every QR code is generated dynamically and remains valid only for a limited period (in my implementation, I set this to 11 seconds).

Once it expires, the system rejects it.

This dramatically reduces the opportunity for someone to reuse an older QR code.

Authentication Beyond the QR
Scanning the QR code alone isn't enough.

The backend performs additional validation before marking attendance.

Rather than trusting the client, the server becomes the source of truth.

This reduces opportunities for client-side manipulation and keeps the attendance workflow under server control.

Designing for the Real World
One challenge I encountered was balancing security with usability.

If the QR expires too quickly, students may struggle to scan it in time.

If it stays active for too long, it becomes easier to misuse.

Finding the right balance required thinking about actual classroom conditions rather than only technical implementation.

Lessons Learned
One lesson stood out throughout this project:

Security isn't usually one big feature.

It's the result of multiple smaller decisions working together.

A dynamic QR code helps.

Server-side validation helps.

Short-lived sessions help.

Each layer reduces risk.

What's Next?
This article only covers one piece of the system.

In future posts, I'll explore:

Backend architecture
Firestore data modeling
Authentication flow
Scaling the platform
Engineering decisions behind the project
Building software has taught me that writing code is only part of engineering.

Designing systems that continue to work under real-world conditions is where the interesting problems begin. In this project, I used libraries like qrcode on the backend to generate dynamic QR codes and html5-qrcode on the frontend to scan and verify them efficiently, while SHA-256 hashing was used on the backend to securely generate and validate the QR token payloads.

⭐ GitHub: https://github.com/siddarthpatelkama

💼 LinkedIn: https://www.linkedin.com/in/siddarthpatelkama

JWT Storage: Cookies vs LocalStorage – Which Is Right for Your App?

Sat, 22 Nov 2025 05:19:56 +0000

JWT Storage: Cookies vs LocalStorage

Where should you store JWT tokens? This guide covers both approaches with working code examples to help you make an informed decision.

What You'll Learn

Implement JWT authentication using HTTP-only cookies and localStorage
Understand XSS and CSRF attack implications
Choose the right storage method for your application
Apply defense-in-depth security strategies

The Two Storage Options

HTTP-Only Cookies

Cookies with the httpOnly flag cannot be accessed by JavaScript, providing protection against XSS token theft.

Key characteristics:

Automatic: Browser sends tokens with requests
JavaScript-proof: Cannot be stolen via XSS
Configurable: Secure and SameSite flags for added security
Vulnerable to CSRF without proper protection

LocalStorage

Tokens stored in localStorage require manual attachment to requests via JavaScript.

Key characteristics:

Manual control: You decide when to send tokens
JavaScript-accessible: Easy to use but vulnerable to XSS
CSRF immune: Tokens aren't sent automatically
Developer-managed: You handle storage and cleanup

The Core Trade-off

Cookies are safer from XSS but vulnerable to CSRF. LocalStorage is immune to CSRF but exposed to XSS.

Implementation: Cookies Approach

Backend (Node.js/Express)

const express = require('express');
const jwt = require('jsonwebtoken');
const cookieParser = require('cookie-parser');

const app = express();
app.use(cookieParser());
app.use(express.json());

const JWT_SECRET = process.env.JWT_SECRET || 'your-secret-key';

// Login endpoint
app.post('/api/auth/login', async (req, res) => {
  const { email, password } = req.body;
  const user = await validateUser(email, password);
  
  if (!user) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }
  
  const token = jwt.sign(
    { userId: user.id, email: user.email },
    JWT_SECRET,
    { expiresIn: '15m' }
  );
  
  res.cookie('access_token', token, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    maxAge: 15 * 60 * 1000
  });
  
  res.json({ success: true, user: { id: user.id, email: user.email } });
});

// Protected endpoint
app.get('/api/user/profile', (req, res) => {
  const token = req.cookies['access_token'];
  
  if (!token) {
    return res.status(401).json({ error: 'Not authenticated' });
  }
  
  try {
    const decoded = jwt.verify(token, JWT_SECRET);
    res.json({ user: decoded });
  } catch (error) {
    res.status(401).json({ error: 'Invalid token' });
  }
});

Frontend (React)

async function handleLogin(email, password) {
  const response = await fetch('http://localhost:3000/api/auth/login', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    credentials: 'include', // Critical for cookies
    body: JSON.stringify({ email, password })
  });
  
  const data = await response.json();
  if (response.ok) {
    window.location.href = '/dashboard';
  }
}

// Making authenticated requests
fetch('/api/user/profile', {
  credentials: 'include' // Browser automatically includes cookie
});

Implementation: LocalStorage Approach

Backend

const express = require('express');
const jwt = require('jsonwebtoken');

const app = express();
app.use(express.json());

// Login endpoint - returns token in response body
app.post('/api/auth/login', async (req, res) => {
  const { email, password } = req.body;
  const user = await validateUser(email, password);
  
  if (!user) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }
  
  const token = jwt.sign(
    { userId: user.id, email: user.email },
    JWT_SECRET,
    { expiresIn: '15m' }
  );
  
  res.json({ 
    success: true,
    token: token,
    user: { id: user.id, email: user.email }
  });
});

// Protected endpoint - expects Authorization header
app.get('/api/user/profile', (req, res) => {
  const authHeader = req.headers.authorization;
  
  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Not authenticated' });
  }
  
  const token = authHeader.substring(7);
  
  try {
    const decoded = jwt.verify(token, JWT_SECRET);
    res.json({ user: decoded });
  } catch (error) {
    res.status(401).json({ error: 'Invalid token' });
  }
});

Frontend

async function handleLogin(email, password) {
  const response = await fetch('http://localhost:3000/api/auth/login', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ email, password })
  });
  
  const data = await response.json();
  
  if (response.ok) {
    localStorage.setItem('access_token', data.token);
    window.location.href = '/dashboard';
  }
}

// Making authenticated requests
const token = localStorage.getItem('access_token');
fetch('/api/user/profile', {
  headers: {
    'Authorization': `Bearer ${token}`
  }
});

Security Deep Dive

XSS Attacks

LocalStorage: If XSS occurs, attackers can trivially steal tokens with localStorage.getItem('access_token') and use them from anywhere.

HTTP-Only Cookies: JavaScript cannot read the token. Attackers can make requests during XSS but cannot steal the token for later use.

CSRF Attacks

Cookies: Browsers automatically send cookies with requests, even from malicious sites. Use SameSite cookies and CSRF tokens for protection.

LocalStorage: Immune to CSRF because tokens must be manually attached via JavaScript, which cannot access cross-origin localStorage.

Making the Decision

Choose HTTP-Only Cookies if:

Building financial, healthcare, or high-security applications
Frontend and backend share a domain
Using server-side rendering (Next.js, Remix)
Security is top priority

Choose LocalStorage if:

Building a modern SPA (React, Vue, Angular)
Cross-origin setup with CORS complexity
Building mobile or hybrid apps
Using GraphQL or custom protocols
Have strong XSS prevention (CSP, security audits)

Hybrid Approach (Best Security)

Store short-lived access tokens in memory (5-15 min) and long-lived refresh tokens in HTTP-only cookies. This combines the benefits of both approaches.

Best Practices

Universal (Do These Always)

Always use HTTPS in production
Keep tokens short-lived (15-30 minutes)
Implement token rotation
Build proper logout (clear client + invalidate server)
Log authentication events and monitor patterns

XSS Prevention

Implement Content Security Policy (CSP)
Sanitize user input with libraries like DOMPurify
Avoid dangerous DOM manipulation (innerHTML, eval)
Keep dependencies updated (npm audit)

CSRF Prevention (For Cookies)

Use SameSite cookie attribute ('strict' or 'lax')
Implement CSRF tokens for sensitive operations
Validate request origins

Troubleshooting

Cookies not sent cross-origin

Backend: Set CORS with credentials: true. Frontend: Use credentials: 'include' in fetch.

SameSite=None not working

Requires Secure flag (HTTPS only).

Tokens not syncing across tabs (localStorage)

Listen to storage events to detect changes in other tabs.

Conclusion

HTTP-only cookies protect against XSS token theft but require CSRF protection. LocalStorage is immune to CSRF but vulnerable to XSS. The hybrid approach offers the best security.

For high-security apps, use cookies or hybrid. For modern SPAs with strong XSS prevention, localStorage is acceptable. Remember: security is a process, not a checkbox.

For a more detailed version of this guide with additional examples, troubleshooting scenarios, and in-depth explanations, visit: https://stackinsight.dev/blog/jwt-storage-cookies-vs-localstorage-which-is-right-for-your-app/

Coder Legion - Recent posts tagged web-security

Enterprise Cloud WAF vs Self-Hosted: A Cost-and-Control Breakdown

Enterprise Cloud WAF vs Self-Hosted: A Cost-and-Control Breakdown

Control

Cost

Where each fits

Getting started self-hosted

FAQ

Is self-hosted "enterprise-grade"?

Do I lose the CDN with self-hosted?

Which is faster to deploy?

Appliance WAF vs Container WAF: The Deployment Trade-off

Appliance WAF vs Container WAF: The Deployment Trade-off

The appliance model

The container model

Comparing the trade-offs

Which should you choose?

FAQ

Does SafeLine need dedicated hardware?

Can a container WAF block the same attacks as an appliance?

Which is faster to deploy?

Appliance WAF vs Container WAF: The Deployment Trade-off

Appliance WAF vs Container WAF: The Deployment Trade-off

The appliance model

The container model

Comparing the trade-offs

Which should you choose?

FAQ

Does SafeLine need dedicated hardware?

Can a container WAF block the same attacks as an appliance?

Which is faster to deploy?

Enterprise Cloud WAF vs Self-Hosted: A Cost-and-Control Breakdown

Enterprise Cloud WAF vs Self-Hosted: A Cost-and-Control Breakdown

Control

Cost

Where each fits

Getting started self-hosted

FAQ

Is self-hosted "enterprise-grade"?

Do I lose the CDN with self-hosted?

Which is faster to deploy?

WAF 101: What Actually Happens When a Request Hits Your Firewall

WAF 101: What Actually Happens When a Request Hits Your Firewall

1. The request hits the proxy

2. It parses the request

3. It makes a decision

4. Two ways it detects attacks

5. Clean traffic moves on

Why placement matters

FAQ

Does a WAF replace my network firewall?

Will it slow my site?

Is a WAF enough on its own?

Self-Hosted vs Managed WAF: Which Deployment Fits Your Team?

Self-Hosted vs Managed WAF: Which Deployment Fits Your Team?

Two deployment models

What you actually give up or keep

How to decide

The bottom line

What Is Authentication? A Beginner's Guide (2026)

What Is Authentication? (Quick Answer)

Why Authentication Matters

Authentication vs. Authorization: The Difference That Trips Everyone Up

How Authentication Works (Step by Step)

The Main Types of Authentication

1. Password-Based Authentication

2. Session-Based Authentication

3. Token-Based Authentication (JWT)

4. OAuth / OpenID Connect (Social Login)

5. Multi-Factor Authentication (MFA / 2FA)

6. Passwordless Authentication (Magic Links & Passkeys)

A Minimal Authentication Flow in Next.js

Common Authentication Mistakes to Avoid

Frequently Asked Questions

What is the difference between authentication and authorization?

Is a login system the same thing as authentication?

What's the difference between sessions and JWTs?

Do I need a library to build authentication, or can I build it myself?

Is two-factor authentication (2FA) actually necessary?

Are passkeys better than passwords?