SecureStartKit
SecurityFeaturesPricingDocsBlogChangelog
Sign inBuy Now
Home/Glossary

Security Glossary

Canonical definitions of the 26 security, auth, payments, and data-layer terms used across the SecureStartKit blog, free tools, and docs. Each entry links to the cluster pillar that goes deep on the topic.

Categories

  • Authentication (10)
  • Application Security (5)
  • Data Layer (4)
  • Payments (2)
  • Vulnerability Patterns (4)
  • AI Security (1)

Authentication

JWT lifecycle, OAuth/PKCE, magic links, MFA, and the Supabase Auth surface.

  • @supabase/ssr@supabase/ssr is the official Supabase package for server-side authentication in Next.js, SvelteKit, and other SSR frameworks. It manages JWT storage in httpOnly cookies, handles the OAuth and magic-link callback cookie writes, and exposes createServerClient and createBrowserClient helpers for each context.
  • AAL(Authenticator Assurance Level)AAL (Authenticator Assurance Level) is a JWT claim that reflects how strongly the user authenticated. AAL1 means one factor (password, OAuth, magic link). AAL2 means a second factor verified for this session (TOTP code). RLS policies read `auth.jwt() ->> 'aal'` to gate sensitive operations.
  • Custom Access Token HookA Custom Access Token Hook is a Supabase Auth Hook that runs a Postgres function on every JWT issuance to inject custom claims. Typical uses include adding tenant_id and role claims for multi-tenancy, which then become readable inside RLS policies via auth.jwt().
  • getClaimsgetClaims is the Supabase Auth method that locally validates a JWT against the cached public key from the project's JWKS endpoint and returns the parsed claims. It replaces getSession for authorization because getSession reads the cookie without re-validating the signature.
  • JWT(JSON Web Token)A JWT is a signed, base64url-encoded token carrying claims about a user. Supabase issues JWTs after authentication, signs them with ES256 asymmetric keys (default for new projects since October 2025), and Next.js apps validate them server-side via getClaims without a network round trip to the auth server.
  • Magic linkA magic link is a one-time email token that exchanges for a Supabase session when clicked. Magic links are single-use, rate-limited (default one per 60 seconds per user), expire after one hour, and use the PKCE flow when configured with token-hash email templates.
  • MFA(Multi-Factor Authentication)MFA (Multi-Factor Authentication) requires a user to prove identity with a second factor beyond their password or OAuth login. In Supabase, MFA is implemented via TOTP (authenticator app) or phone (SMS). Successful verification promotes the session to AAL2, which RLS policies can gate on.
  • OAuthOAuth is an open standard for delegated authorization, used in Supabase apps as federated sign-in via providers like Google, GitHub, and Apple. The user authenticates with the provider, the provider returns an authorization code to a callback route, and the server exchanges the code for a Supabase session via PKCE.
  • PKCE(Proof Key for Code Exchange)PKCE (Proof Key for Code Exchange) is the OAuth 2.1 flow that prevents authorization-code interception by browser-based clients. The client generates a verifier, hashes it into a challenge, sends the challenge with the auth request, and presents the original verifier at the code-exchange step. An attacker who steals the code alone cannot complete the exchange.
  • TOTP(Time-based One-Time Password)TOTP (Time-based One-Time Password) is a six-digit code generated every 30 seconds from a shared secret. The user scans a QR code at enrollment, their authenticator app derives the secret, and Supabase verifies the code by computing the same derivation. TOTP is the recommended MFA factor over SMS.

Application Security

Server Actions, Zod validation, security headers, CORS, and rate limiting.

  • CORS(Cross-Origin Resource Sharing)CORS (Cross-Origin Resource Sharing) is the browser mechanism that controls which origins can call which API endpoints. The server declares allowed origins via Access-Control-Allow-Origin headers, and the browser blocks cross-origin requests that fail the check.
  • CSP(Content Security Policy)CSP (Content Security Policy) is an HTTP response header that tells the browser which sources of scripts, styles, images, and other resources are allowed to load on a page. A well-configured CSP blocks injected scripts even if an XSS vulnerability exists in the application code.
  • Rate limitingRate limiting is the practice of capping how many times an endpoint can be called per user, IP, or other identifier within a time window. In Next.js Server Actions, rate limits protect login, signup, password reset, magic links, and any expensive operation against brute-force and enumeration attacks.
  • Server ActionsServer Actions are Next.js functions marked with the 'use server' directive that run on the server and can be called from client components. Every Server Action is a public HTTP endpoint and must validate inputs with Zod, authorize identity from the session, and never trust user IDs from the request payload.
  • ZodZod is a TypeScript-first schema validation library that parses unknown input against a typed schema and returns either typed data or a structured error. In Server Actions, Zod is the validation layer that runs before any business logic, rejecting malformed or hostile input at the boundary.

Data Layer

Row Level Security, anon vs service_role, and backend-only data access.

  • Anon keyThe anon key is the Supabase public API key that respects Row Level Security. It is safe to include in the browser bundle because RLS gates every query against the user's JWT claims. The anon key alone cannot read or modify rows unless an RLS policy explicitly allows it.
  • Backend-only data accessBackend-only data access is an architectural pattern where the database is never queried directly from the browser. All queries run through Server Actions or Route Handlers using the service_role key, after server-side authentication and Zod validation. The browser only receives data the server explicitly returns.
  • Row Level Security(RLS)Row Level Security is a Postgres feature that filters which rows of a table each user can see or modify. In Supabase apps, RLS policies are written in SQL and evaluated on every query against the authenticated user's JWT claims, making the database itself the authorization boundary.
  • Service role keyThe service role key is the Supabase API key that bypasses Row Level Security and grants full database access. It must never enter the browser bundle. In a Next.js app, the service role key is used only in Server Actions and Route Handlers via createAdminClient, with the import gated by Next.js's server-only enforcement.

Payments

Stripe webhook signature verification and idempotency patterns.

  • IdempotencyIdempotency is the property that running an operation multiple times produces the same result as running it once. For Stripe webhook handlers, idempotency means storing every processed event.id in a unique-constraint table so retries (Stripe retries failed deliveries for up to 3 days in live mode) cannot duplicate purchases or emails.
  • Stripe webhook signature verificationStripe webhook signature verification is the HMAC-SHA256 check that proves a webhook payload came from Stripe and was not modified in transit. The Stripe-Signature header carries a timestamp and signature; the receiver recomputes HMAC over the raw body with the endpoint secret and compares.

Vulnerability Patterns

OWASP-cataloged classes: CSRF, XSS, IDOR, and how they map to Next.js + Supabase.

  • CSRF(Cross-Site Request Forgery)CSRF (Cross-Site Request Forgery) is an attack where a malicious site causes the victim's browser to send a request to a target site using the victim's existing session cookies. In Next.js App Router, Server Actions defend against CSRF by checking the Origin header against the Host on every POST.
  • IDOR(Insecure Direct Object Reference)IDOR (Insecure Direct Object Reference) is a vulnerability class where an application uses a user-supplied identifier (such as a userId or recordId) to look up data without verifying the requester is authorized to access that specific object. IDOR is the most common Server Action bug in AI-generated Next.js code.
  • OWASP Top 10The OWASP Top 10 is the consensus list of the ten most critical web application security risks, updated by the Open Worldwide Application Security Project. The 2025 edition (current as of 2026) includes Broken Access Control as A01, Cryptographic Failures as A02, and a new A10 for Mishandling of Exceptional Conditions.
  • XSS(Cross-Site Scripting)XSS (Cross-Site Scripting) is a vulnerability where attacker-controlled content reaches a page and executes as JavaScript in the victim's browser. React mitigates XSS by default through JSX escaping, but the raw-HTML escape-hatch prop, raw HTML in MDX, and trusted-data assumptions still create injection paths.

AI Security

Vibe-coding security failures and the migration path to production-ready architecture.

  • Vibe codingVibe coding is the practice of building applications primarily through AI code generation (Copilot, Cursor, Lovable, Bolt, v0) with minimal manual review. The pattern produces shippable prototypes quickly but introduces a documented class of security bugs, including service_role in client bundles, missing input validation, and IDOR.