DEV Community: Sadeq Sheikhi

Passkeys Explained: How Passwordless Authentication Works

Sadeq Sheikhi — Sat, 29 Aug 2026 11:50:02 +0000

Passkeys have been around for a while now. You have probably seen them on larger websites such as GitHub and Google, where you can sign in without typing a password at all.

And every time I used them, I had basically the same thought: why don't more normal websites use this?

I wanted passkeys on my own website and products for a pretty simple reason: the experience is just better. You don't have to remember a password, open a password manager, copy anything, or wait for a verification code. You choose your passkey, confirm with your fingerprint, face, device PIN, or another authenticator, and you're in.

It feels almost suspiciously easy for something that is also, when implemented correctly, significantly more resistant to common attacks such as phishing and credential stuffing than traditional password-based authentication.

But once I started looking into actually implementing passkeys, I realized there is quite a bit happening underneath that simple fingerprint prompt. There is WebAuthn, FIDO2, public-key cryptography, relying parties, challenges, authenticators, credential IDs, discoverable credentials, browser APIs, and a few important decisions your backend needs to get right.

So this article is the conceptual part. We are going to look at what passkeys actually are, how they work, which standards are involved, what the browser and authenticator are really doing, what your frontend and backend are responsible for, and what happens in real-world situations such as losing your phone or signing in on another computer.

In a follow-up article, I will move from the theory to the actual implementation and build passkey authentication with Vue and Nuxt.

Let's get into it.

What are passkeys?

The easiest way to think about a passkey is as a replacement for a password that uses the security already built into your device.

Instead of typing a secret string that both you and the server need to somehow protect, you authenticate using something such as a fingerprint, face scan, device PIN, password manager, or hardware security key.

Underneath that much nicer user experience, passkeys are built on the Web Authentication API, usually called WebAuthn, and public-key cryptography.

If you want a more developer-friendly introduction than the raw W3C specification, the MDN Web Authentication API guide is also a very good reference.

When you create a passkey, an authenticator creates a cryptographic key pair:

The private key is controlled by the authenticator or passkey provider and is not sent to your application during registration or authentication.
The public key is returned to your application and stored on your server.

This distinction is the entire foundation of how passkeys work.

With passwords, the user and the server are ultimately dealing with the same secret. Ideally the server stores only a strong hash of the password, but the user still has to know or possess the original secret and send proof of it during login.

Passkeys change that model completely.

Your server does not know the secret used to authenticate. It only knows a public key that can verify signatures created by the corresponding private key.

If someone steals the public key from your database, they cannot use it to generate valid signatures. It is designed to be public.

This is one of the reasons a database containing passkey credentials is fundamentally different from a database containing password hashes.

The browser, authenticator, and server are different parts of the system

This is where passkeys became much clearer to me.

When you click something like Create a passkey, there are actually several different actors involved:

Your application frontend, which starts the process.
Your backend, which generates challenges and verifies the final response.
The browser, which implements the WebAuthn API and enforces rules around origins and relying parties.
The authenticator, which holds or controls the private key and performs cryptographic operations.
The user, who authorizes the authenticator through a fingerprint, face scan, device PIN, hardware key, or another verification mechanism.

The browser and authenticator are related, but they are not the same thing.

The browser is basically the bridge between your website and the authenticator.

Your JavaScript asks the browser to create or use a credential through WebAuthn. The browser checks whether the request makes sense for the current website, communicates with an appropriate authenticator, gets the result back, and returns a WebAuthn response to your frontend.

When the authenticator is external, such as a hardware security key or another device, communication can happen through the Client to Authenticator Protocol, or CTAP. CTAP is the other major piece of FIDO2 alongside WebAuthn.

The authenticator is the component that actually controls the credential.

Depending on the device and setup, that authenticator might be:

Windows Hello on a Windows computer.
Touch ID or Face ID backed by Apple's credential system.
An Android device using the platform's credential manager.
A password manager capable of storing and synchronizing passkeys.
A physical FIDO2 security key.
A phone being used to authenticate a login on another computer.

So when people say, "the private key stays on the device," that is useful as a simplified explanation, but the reality is slightly more nuanced.

The important security property is that your website never receives the private key.

The authenticator or passkey provider controls it and exposes only specific operations such as "create a credential" and "sign this authentication request."

Your fingerprint is not your passkey

This is another distinction worth making because the user experience can make it seem like your fingerprint itself is being sent to the website.

It is not.

Your fingerprint, face scan, or device PIN usually exists to unlock or authorize the authenticator.

For example, imagine that your laptop contains a passkey for example.com. When you sign in, the website asks the browser to authenticate. The browser asks the authenticator to use the relevant credential.

The authenticator may then say: "Before I use this private key, prove that the actual device user is present."

Windows Hello might ask for your fingerprint. An iPhone might ask for Face ID. A security key might require you to physically touch it.

Once that local check succeeds, the authenticator is allowed to use the private key to produce a cryptographic signature.

The website receives the signature.

It does not receive your fingerprint image, Face ID data, Windows PIN, or other biometric information.

That verification remains local to the authenticator and operating system.

What exactly is stored inside a passkey?

A passkey is not just "a private key with a website name attached to it."

Conceptually, a credential is associated with several pieces of information that allow the browser, authenticator, and server to identify and use it correctly.

The exact internal representation depends on the authenticator, but from the application's point of view, some of the most important pieces are:

Credential ID — a unique identifier for this specific credential.
Private key — controlled by the authenticator and used to sign authentication data.
Public key — stored by your server and used to verify those signatures.
Relying Party ID — the website or domain scope the credential belongs to.
User handle — an application-defined stable identifier that can associate the credential with a user.
Discoverability information — for credentials that can be presented before the user enters an email or username.
Authenticator-specific metadata — depending on the implementation and platform.

Your server does not need to understand how the authenticator internally stores the private key.

That is deliberately abstracted away.

Your application mostly cares about the credential ID, public key, user relationship, and the information required to verify future authentication responses.

What the server normally stores for a passkey

When a passkey is registered successfully, you normally create a record in your own database representing that credential.

A simplified database model might contain values such as:

User ID — which account owns the passkey.
Credential ID — the identifier returned by WebAuthn.
Public key — used to verify future signatures.
Signature counter — when provided and relevant for the authenticator.
Transport information — hints about how the authenticator can be reached.
Device or credential name — often something you add yourself for the user's convenience.
Created date — useful for account management and security history.
Last-used date — useful for displaying credentials and security monitoring.
Backup or authenticator information — depending on what your WebAuthn library exposes and what you actually need.

Some of this information comes directly from WebAuthn. Some of it is metadata your application adds on top.

For example, WebAuthn does not magically know that you want to show the user a settings page saying:

MacBook Pro — added August 28 — last used two hours ago.

You build that product layer yourself.

You might ask the user to name a passkey when they create it, or automatically give it a generic label and allow them to rename it later.

That metadata is not part of the cryptographic secret. It simply makes credential management understandable to humans.

Credential IDs are important

The credential ID deserves more attention because it appears throughout a WebAuthn implementation.

Imagine a user has three passkeys registered:

One on their laptop.
One in a password manager.
One on a physical security key.

All three belong to the same user, but each is a separate credential with its own credential ID and key material.

When an authentication response comes back, the credential ID tells your backend which stored public key should be used to verify the signature.

Your server can effectively say:

"This response says it came from credential ABC123. Let me find credential ABC123, get its public key, and verify the signature."

If the signature verifies and the rest of the WebAuthn checks pass, the server can then look at the owner of that credential and know which user is signing in.

This is also why users can have multiple passkeys attached to one account without your application becoming confused about which one was used.

What is an authenticator?

The word authenticator sounds more complicated than it really is.

An authenticator is basically the trusted component responsible for creating and using WebAuthn credentials.

It can usually perform operations like:

Create a new credential and key pair.
Store or control access to that credential.
Ask the user for verification when required.
Sign authentication data with the credential's private key.
Return the credential ID and signed response to the browser.

Authenticators are often divided into two broad categories.

Platform authenticators

A platform authenticator is integrated into the device you are already using.

Windows Hello is a good example.

You are on your laptop, you create a passkey, and later you authenticate using the laptop's fingerprint reader, face recognition, or PIN.

The user does not have to plug anything in.

Roaming authenticators

A roaming authenticator is separate from the device running the browser.

A physical security key is the classic example.

You might create a credential on a USB or NFC security key and then use that key across multiple computers.

Modern passkey ecosystems blur these categories a little because phones can also act as authenticators for nearby computers, and passkey providers may synchronize credentials across multiple devices.

But the mental model remains useful: the authenticator is the thing that controls the credential and performs the cryptographic operation.

What does the browser actually do?

The browser is doing much more than displaying a nice fingerprint popup.

When your frontend calls WebAuthn, the browser participates in enforcing some of the most important security boundaries in the protocol.

It knows which origin your JavaScript is running on.

It knows which relying party the website is requesting a credential for.

It communicates with available authenticators through the operating system and supported authenticator protocols.

It also packages WebAuthn data in a standardized structure that your backend can later verify.

This is why WebAuthn is fundamentally different from building a custom JavaScript authentication protocol yourself.

Your application cannot simply tell the authenticator:

"Pretend I am google.com and give me Google's credential."

The browser and authenticator participate in checking whether the relying-party request matches the current web context.

How passkey registration works in detail

There are two major WebAuthn ceremonies: registration and authentication.

Registration is where a new credential is created.

The process starts on the backend, not inside the authenticator.

Your backend generates a random challenge and creates a set of registration options. Those options describe things such as:

The challenge.
The relying party.
The user identifier.
The user's display information.
Whether user verification is required.
Whether you prefer a discoverable credential.
Credentials that should be excluded because they already exist.
Cryptographic algorithms the server accepts.

Your frontend receives those options and passes them to the browser.

sequenceDiagram
    participant U as User
    participant B as Browser
    participant S as Application server
    participant A as Authenticator
    participant D as Database

    U->>B: Choose "Create a passkey"
    B->>S: POST /passkeys/register/options
    S->>S: Generate random challenge
    S->>S: Set RP ID, origin, user ID, and user verification policy
    S-->>B: Creation options and challenge cookie
    B->>A: navigator.credentials.create(options)
    U->>A: Unlock with fingerprint, face, PIN, or security key
    A->>A: Generate key pair and retain private key
    A-->>B: Return credential ID and public key
    B->>S: POST /passkeys/register/verify(response)
    S->>S: Read and consume challenge
    S->>S: Verify origin, RP ID, challenge, and user verification
    S->>D: Store credential ID, public key, counter, and metadata
    S-->>B: Registration succeeded

Once the browser receives those options, it invokes an authenticator.

The authenticator may ask the user for local verification.

Then it creates the credential and generates its key pair.

The private key remains under the authenticator's control.

The browser receives a registration response containing information that allows your server to verify what just happened.

This registration response is commonly referred to as an attestation response.

The server then verifies several things before trusting it.

Among them:

Was this response created for the challenge we just issued?
Has that challenge already been used?
Does the origin match the website we expect?
Does the relying-party information match?
Was user verification performed if we required it?
Can the credential data be parsed and cryptographically validated?

Only after those checks succeed do you save the credential.

This is why the registration response should never simply be accepted because "the browser sent it."

The browser is part of the protocol, but your backend still treats anything arriving over HTTP as untrusted input.

Attestation does not mean your server receives the private key

The name attestation can make the registration response sound as if the authenticator is handing your backend everything about itself.

It is not.

The important result for your application is that you receive the newly created credential's public information and enough signed or structured data to validate the registration ceremony.

The private key does not come along for the ride.

Your WebAuthn library typically parses the registration response and gives you the pieces you actually need to store, such as the credential ID, public key, and counter.

Depending on your authenticator policy and implementation, attestation can contain additional information about the authenticator. Many consumer-facing applications do not need to build their product around identifying the exact hardware model of every authenticator.

In most normal web applications, your real goal is simpler:

Did a valid authenticator create a valid credential for the correct user and the correct website in response to the challenge I generated?

How passkey authentication works

Authentication is the second ceremony.

This time, no new key pair needs to be generated.

Your server wants the authenticator to prove that it controls the private key corresponding to one of the public keys you already have stored.

Again, the backend begins by generating a fresh random challenge.

sequenceDiagram
    participant U as User
    participant B as Browser
    participant S as Application server
    participant A as Authenticator
    participant D as Database

    U->>B: Choose "Sign in with a passkey"
    B->>S: POST /passkeys/authenticate/options
    S->>S: Generate fresh challenge
    S-->>B: Request options + challenge cookie
    B->>A: navigator.credentials.get(options)
    U->>A: Unlock authenticator
    A->>A: Sign challenge + origin + RP data with private key
    A-->>B: Assertion: credential ID + signature
    B->>S: POST /passkeys/authenticate/verify(assertion)
    S->>D: Find credential by credential ID
    S->>S: Verify signature with stored public key
    S->>S: Check challenge, origin, RP ID, user verification, counter
    S->>S: Create authenticated session
    S-->>B: Session cookies / tokens

The browser asks the authenticator for a matching credential.

The authenticator may ask the user to verify themselves locally.

Once authorized, the authenticator signs data related to the authentication ceremony using the private key.

The result sent back to the server is generally called an assertion.

The assertion includes the credential ID, which allows your backend to identify the correct stored credential.

Your backend finds that database record, loads its public key, and asks the WebAuthn verification library to verify the signature and the surrounding protocol data.

If everything checks out, you now know that the party producing the response controls the private key corresponding to the public key you stored during registration.

Notice what did not happen.

The private key was never sent to your backend.
The user did not send a reusable password.
The fingerprint was never sent to your backend.
The server did not decrypt anything using the public key.

The server simply verified a signature.

Why the challenge matters

The challenge is one of those details that can look like boring protocol plumbing until you realize what attack it prevents.

Suppose an attacker somehow records a valid authentication response from yesterday.

Without a fresh challenge, they could potentially send that exact response to your server again.

A challenge prevents that.

Your server generates a random value specifically for the current authentication attempt. The signed response is tied to that value.

If someone replays an old response, it contains an old challenge and verification fails.

This is why challenges should be:

Cryptographically random.
Short-lived.
Associated with the correct ceremony or session.
Consumed after successful or attempted use according to your design.

You should not generate a permanent "challenge" once for every user and keep reusing it forever.

Why passkeys are resistant to phishing

This is one of the parts I found particularly interesting.

A WebAuthn credential is scoped to something called a relying party ID, or RP ID, which is normally related to the website's domain.

A passkey created for example.com cannot simply be used by evil-example.com.

The browser and authenticator participate in enforcing this relationship.

So imagine an attacker builds a perfect clone of your login screen.

With a traditional password, the user can accidentally type their real password into the fake website. The attacker now possesses something reusable.

With WebAuthn, the fake website does not get to simply request a valid credential for the real domain.

The credential is tied to the relying party it was created for.

There is no equivalent of "just type your passkey into this phishing form."

This is one of the strongest conceptual improvements passkeys bring to everyday authentication.

What is the RP ID?

The RP ID is another detail that becomes extremely important when you move from local development to production.

RP stands for Relying Party. In this case, your application is the relying party because it relies on the authenticator to prove the user's identity.

The RP ID is normally your application's domain or an appropriate registrable domain scope.

It determines which website context a credential belongs to.

If you configure it incorrectly, passkeys that worked beautifully on localhost can suddenly fail in production.

It is especially important when dealing with:

Subdomains.
Separate frontend and API hosts.
Development versus production environments.
Preview deployments.
Multiple products sharing authentication infrastructure.

Your expected origin and RP ID should be explicit configuration, not something you casually infer from whatever host header happened to arrive in a request.

Discoverable credentials and username-less login

Another nice part of passkeys is that they can support a completely username-less login experience.

Traditionally, your server needs to know the user's account first.

The user enters:

user@example.com

Your backend then looks up that user and figures out which authentication methods belong to the account.

Discoverable credentials can reverse that flow.

The browser or authenticator can present credentials that match the current relying party before your server knows which account the user wants.

The user can select a passkey, authenticate, and the resulting credential tells your backend which account owns it.

This is how you can build a login screen where the user does not type an email address at all.

You can also keep a username-first flow.

In that version, the user enters an email address first. Your backend finds the credentials associated with that account and sends those credential IDs in allowCredentials.

The browser then knows which credentials are acceptable for that specific authentication attempt.

Both approaches are valid.

Personally, I find the discoverable flow much more interesting because that is where passkeys stop feeling like "passwords but with a fingerprint" and start changing the actual login experience.

Synced passkeys versus device-bound credentials

One phrase you will often hear is:

The private key never leaves your device.

That is a useful beginner explanation, but with modern synced passkeys it can also become misleading if taken too literally.

Some passkey ecosystems can securely synchronize a user's credentials across devices through a credential provider.

That is how a passkey created on one device may later appear on another device belonging to the same user.

The MDN passkeys guide is a useful reference if you want to dig further into synced passkeys, authentication flows, and credential management.

From your application's point of view, the important guarantee remains the same:

Your application never receives the private key.

You do not export it from WebAuthn, store it in your database, or send it back to the browser during authentication.

How a passkey provider protects or synchronizes its credential material is part of that provider's security architecture.

Other credentials may be device-bound.

For example, a hardware security key may contain a credential that remains associated with that physical authenticator.

This distinction matters when thinking about recovery and cross-device usage.

What should the frontend do?

One mistake I initially expected to make was thinking that implementing passkeys would involve writing a lot of cryptography in the frontend.

Thankfully, it should not.

The frontend's job is mostly orchestration.

It asks your backend for WebAuthn options, passes those options into a WebAuthn-capable browser API or client library, and sends the resulting response back to the server.

The browser and authenticator handle the sensitive cryptographic operations.

async function registerPasskey(deviceName?: string) {
  const options = await post('/api/passkeys/register/options')
  const response = await startRegistration({ optionsJSON: options })

  return post('/api/passkeys/register/verify', {
    response,
    deviceName,
  })
}

async function signInWithPasskey() {
  const options = await post('/api/passkeys/authenticate/options')
  const response = await startAuthentication({ optionsJSON: options })

  return post('/api/passkeys/authenticate/verify', { response })
}

The frontend should not be trusted to decide whether authentication succeeded.

It should not say:

The browser returned something, therefore the user is authenticated.

The backend still has to verify the cryptographic response.

The frontend also needs to handle the less glamorous UX cases:

The user cancels the passkey prompt.
No compatible authenticator is available.
The ceremony times out.
The challenge expires.
The browser does not support the required flow.
The requested credential cannot be found.

A cancelled fingerprint dialog is not necessarily a server error.

Your UI should treat user cancellation as a normal outcome rather than showing some terrifying red error banner every time someone changes their mind.

What should the backend do?

The backend is where most of the security-sensitive verification happens.

I would strongly avoid implementing the WebAuthn parsing and cryptographic verification yourself.

This is exactly the kind of protocol where using a mature, maintained library is much better than trying to be clever.

Your backend is responsible for things such as:

Generating secure registration and authentication challenges.
Creating WebAuthn options.
Associating registration with the correct authenticated user.
Verifying registration responses.
Saving credential public information.
Looking up credentials during authentication.
Verifying authentication assertions.
Updating relevant credential state.
Creating the final application session.

// Registration options
const options = await generateRegistrationOptions({
  rpID,
  rpName,
  userID: encodeUserId(user.id),
  userName: user.email,
  excludeCredentials: existingCredentials,
  authenticatorSelection: {
    residentKey: 'preferred',
    userVerification: 'required',
  },
})
await saveShortLivedChallenge(event, options.challenge)
return options

// Registration verification
const challenge = await consumeChallenge(event)
const result = await verifyRegistrationResponse({
  response: body.response,
  expectedChallenge: challenge,
  expectedOrigin: passkeyOrigin,
  expectedRPID: rpID,
  requireUserVerification: true,
})
if (!result.verified) throw unauthorized()
await credentials.insert({
  userId,
  credentialId: result.registrationInfo.credential.id,
  publicKey: result.registrationInfo.credential.publicKey,
  counter: result.registrationInfo.credential.counter,
})

// Authentication verification
const challenge = await consumeChallenge(event)
const credential = await credentials.findByCredentialId(body.response.id)
if (!credential) throw unauthorized()
const result = await verifyAuthenticationResponse({
  response: body.response,
  expectedChallenge: challenge,
  expectedOrigin: passkeyOrigin,
  expectedRPID: rpID,
  requireUserVerification: true,
  credential,
})
if (!result.verified) throw unauthorized()
await credentials.updateCounter(credential.id, result.authenticationInfo.newCounter)
return issueSession(credential.userId)

The code itself doesn't look particularly scary.

The dangerous part is getting the assumptions around it wrong.

In production, you need to care about exact origin and RP ID configuration, challenge lifetime, replay protection, authorization, account state, secure cookies, rate limiting, credential-management permissions, and recovery.

Your authentication endpoint should not create a session until the WebAuthn response has been fully verified.

Your credential deletion endpoint should not remove a passkey just because someone knows its credential ID.

Your registration endpoint should not allow someone to attach a passkey to another user's account.

These things sound obvious when written down, but most authentication vulnerabilities live in exactly these surrounding application rules rather than in the cryptography itself.

What about signature counters?

You will often see a counter stored alongside a WebAuthn credential.

Historically, authenticators could increment a signature counter whenever the credential was used. The server could compare the new value against the previous one.

If the server saw something strange, such as a counter unexpectedly moving backward or being reused, it could potentially indicate that a credential had been cloned.

In practice, you should not build your entire passkey security model around signature counters.

Different authenticators behave differently, and some modern authenticators or synced passkeys may not give you a useful monotonically increasing counter in the way older explanations of WebAuthn sometimes imply.

The correct approach is generally to let your WebAuthn library handle the protocol behavior and store the counter information it expects, rather than inventing your own cloned-authenticator detection logic.

Metadata is part of the product experience, not just the protocol

The cryptographic side of passkeys gets most of the attention, but there is another layer that matters a lot once you actually ship this to users: credential management.

If someone has four passkeys, they need some way to understand what they are looking at.

A settings page might show:

Windows laptop — added August 21 — last used today.
1Password — added August 12 — last used August 25.
Security key — added July 3 — last used August 1.

WebAuthn does not automatically give you a perfect human-readable name for every credential.

Your application may need to create that layer.

For example, when a user creates a passkey, you might ask:

What should we call this passkey?

Or you might create a generic name and let them edit it later.

You can also store application metadata such as:

When the credential was registered.
When it was last successfully used.
A user-defined name.
Whether your application considers it a recovery credential.
Potentially browser or authenticator information where appropriate.

You should be careful not to turn this into invasive device fingerprinting just because you can collect metadata.

Store what genuinely improves security or usability.

Credential management deserves its own security rules

Once passkeys exist, users need to be able to manage them.

Usually that means allowing them to:

See registered passkeys.
Add another passkey.
Rename a passkey.
Remove a lost or old passkey.
Potentially see when each passkey was last used.

These actions are security-sensitive.

Imagine an attacker manages to hijack a user's browser session for five minutes.

If they can silently add their own passkey, they may turn a temporary session compromise into persistent access.

That means adding or deleting authentication methods may deserve stronger protections than editing a profile photo.

Depending on the value of the account, you might require recent authentication, another passkey confirmation, a notification to the user, or additional recovery controls when credentials change.

Recovery is part of passkey authentication

Passkeys solve a lot of password problems, but they do not remove the concept of account recovery.

Users lose phones.

Laptops die.

People forget device PINs.

Security keys disappear.

Cloud accounts get locked.

A serious passkey implementation needs to answer:

What happens now?

Synced passkeys make this easier because a user's credentials may become available again through their platform account on a new device.

But you cannot assume that every user will always have access to a synced credential.

One useful strategy is allowing users to register multiple passkeys.

For example:

Laptop passkey.
Phone or synced-provider passkey.
Hardware security key.

Then losing one authenticator does not necessarily mean losing the entire account.

You can still provide another recovery method, but remember something important:

Your account is only as secure as its easiest recovery path.

If the user has incredibly strong phishing-resistant passkey authentication but an attacker can click Forgot access? and take over the account through a weak recovery email flow, your passkey implementation has not achieved nearly as much as it appears to have achieved.

Can passkeys work on another computer?

Yes.

This confused me initially because "the private key is on your device" makes it sound like a passkey should be permanently trapped inside one machine.

There are several ways cross-device authentication can work.

A synced passkey may already be available through the user's credential provider on another device.

A phone can also be used as an authenticator for a nearby computer.

You may have seen this flow already: the computer displays a QR code, you scan it with your phone, confirm that the devices are nearby, authenticate on your phone, and the computer's browser completes the login.

A hardware security key can simply be moved between supported computers.

The exact UX depends on the browser, operating system, authenticator, and credential provider, but passkeys are not inherently limited to the device on which they were originally created.

Passkeys make authentication feel simpler because the complexity moved somewhere better

That is probably my biggest takeaway from learning how passkeys actually work.

Passwords put a surprising amount of responsibility on the user.

We ask people to invent secrets, remember them, avoid reusing them, detect phishing websites, use password managers, and sometimes type another six-digit code afterward.

Then we blame them when one of those steps goes wrong.

Passkeys move much of that responsibility into browsers, authenticators, operating systems, credential providers, and well-defined cryptographic protocols.

The user sees:

Click. Fingerprint. You're in.

Underneath that, however, quite a lot has happened.

Your backend generated a fresh challenge. The browser checked the relying-party context. The authenticator found the correct credential. The user locally unlocked that authenticator. The private key signed the authentication data. The server found the corresponding public key and verified the signature. Only then was the authenticated session created.

And throughout that whole process, the private key never needed to be sent to your application.

That is the part that makes the system so interesting.

The experience became simpler without making the authentication model simpler or weaker underneath.

In the next article, I'll take this into actual code and build the registration, authentication, credential-management, and recovery flow using Vue, Nuxt, and a WebAuthn library on the backend.

Static File Caching in Nuxt: An Easy and Practical Strategy

Sadeq Sheikhi — Tue, 11 Aug 2026 00:29:02 +0000

Lighthouse kept warning me about inefficient cache lifetimes, even though I had already added caching for my static files.

The missing piece was Nuxt Image and its generated /_ipx URLs.

In this post, I’ll share the simple caching setup I use for Nuxt build files, public assets, and optimized images without risking stale content after deployment.

The basic rule is simple:

Cache files aggressively when changing the file also changes its URL. Be more careful when the same URL can serve different content later.

You have probably seen the same Lighthouse warning I have:

Use efficient cache lifetimes.

Browser caching for static files is usually straightforward. You add a Cache-Control header, choose a reasonable lifetime, and the browser avoids downloading the same files again on every visit.

However, in a Nuxt application, not every static-looking file should use the same caching policy.

Nuxt build files are automatically versioned. Files inside public/ usually are not. Nuxt Image also creates transformed image URLs under /_ipx, which need their own cache rule.

In this post, I’ll go through the setup I use, including the Nuxt Image rule that was missing during my latest Lighthouse audit.

The simple caching rule

The most important question is not whether a file is an image, font, or JavaScript file.

The important question is:

Will the URL change when the file changes?

When the answer is yes, you can safely cache the file for a very long time.

When the answer is no, you should use a shorter cache lifetime. Otherwise, visitors may continue seeing an old version after you deploy an update.

What the cache directives mean

Here are the main directives used in this setup:

public allows browsers and shared caches such as CDNs to store the response.
max-age controls how long the browser considers the file fresh.
s-maxage controls how long shared caches such as Cloudflare consider it fresh.
immutable tells the browser that the file is not expected to change while that URL exists.

The important one here is immutable.

You should only use it when changing the file also results in a new URL.

The three main asset types in Nuxt

1. Nuxt build files: `/_nuxt/**`

Nuxt and Vite generate filenames that contain a content hash.

For example:

/_nuxt/entry.Bx3k9Qp2.js

When the file changes, its hash changes too.

That means the URL changes:

/_nuxt/entry.Bx3k9Qp2.js

might become something like:

/_nuxt/entry.Kp8wZ2dA.js

after another deployment.

This makes Nuxt build files perfect candidates for aggressive caching.

You can cache them for a year and use immutable because the next deployment will reference a completely different file when its contents change.

2. Files inside `public/`

Files in Nuxt's public/ directory work differently.

For example:

public/img/logo.png

is served as:

/img/logo.png

The problem is that its URL does not automatically change when the file changes.

You could replace logo.png during your next deployment while keeping exactly the same URL:

/img/logo.png

If that file was cached for a year with immutable, some users could continue seeing the old logo.

For these files, I normally do one of two things:

Give them a reasonable cache lifetime, such as several days or weeks.
Version the filename when I need aggressive caching.

For example:

logo.v2.png

or:

logo.2026-08.png

Once the filename itself changes whenever the content changes, long-term caching becomes much safer.

3. Nuxt Image files: `/_ipx/**`

This is the part that caused my Lighthouse warning.

When you use Nuxt Image with the local IPX provider, the browser often doesn't request your original image directly.

Instead, Nuxt generates a transformed image URL that can look something like this:

/_ipx/q_80&s_640x360/projects/sharmarket.webp

That URL contains information about the requested transformation, such as image quality and dimensions.

So you may have an original image:

/img/project.webp

while the browser actually loads:

/_ipx/q_80&s_640x360/img/project.webp

Those are two completely different HTTP requests.

And therefore, they can have completely different caching headers.

This was exactly what I had missed.

I already had caching configured for my normal image directory, but Lighthouse was complaining about the generated /_ipx request.

Adding a rule for /img/** does not automatically cache /_ipx/**.

There is another important detail here.

I don't treat IPX URLs as completely immutable by default.

Imagine that this source image changes:

/projects/sharmarket.webp

but you keep the same filename.

The corresponding IPX URL may also remain the same:

/_ipx/q_80&s_640x360/projects/sharmarket.webp

even though the image being returned has changed.

Because of that, I give IPX responses a relatively long cache lifetime, but I don't add immutable.

The Nuxt route rules

Here is the setup I currently use:

export default defineNuxtConfig({
  routeRules: {
    '/_nuxt/**': {
      headers: {
        'cache-control':
          'public,max-age=31536000,s-maxage=31536000,immutable',
      },
    },

    '/_ipx/**': {
      headers: {
        'cache-control':
          'public,max-age=2592000,s-maxage=2592000',
      },
    },

    '/img/**': {
      headers: {
        'cache-control':
          'public,max-age=864000,s-maxage=864000',
      },
    },

    '/fonts/**': {
      headers: {
        'cache-control':
          'public,max-age=5184000,s-maxage=5184000',
      },
    },

    '/js/**': {
      headers: {
        'cache-control':
          'public,max-age=2592000,s-maxage=2592000',
      },
    },
  },
})

These values are roughly:

/_nuxt/** → one year
/_ipx/** → 30 days
/img/** → 10 days
/fonts/** → 60 days
/js/** → 30 days

These are not magic numbers.

They are simply reasonable defaults based on how likely each type of file is to change without its URL changing.

Your application may need different values.

Why the IPX rule matters

This distinction is easy to overlook.

Suppose you have:

/img/project.webp

and Nuxt Image generates:

/_ipx/q_80&s_640x360/img/project.webp

A route rule like:

'/img/**': {
  headers: {
    'cache-control': 'public,max-age=864000',
  },
}

only applies to the first URL.

It does not automatically apply to the IPX response.

Your browser, CDN, Lighthouse, and server all see those as different URLs.

So if Lighthouse complains about an image cache lifetime in a Nuxt application, inspect the actual request URL.

If it begins with:

/_ipx/

then changing your /img/** cache rules isn't going to fix it.

You need a separate /_ipx/** rule.

Do not use `immutable` everywhere

It can be tempting to do something like this:

Cache-Control: public,max-age=31536000,immutable

for every static asset.

Lighthouse will probably be happier.

Your future self might not be.

Imagine you have:

/img/logo.png

and you cache it for one year with immutable.

One week later, you deploy a new logo under exactly the same URL.

Some browsers may keep using the old file because you explicitly told them that this URL would not change.

A safer strategy is:

Use very long caching plus immutable for hashed files.
Use it for manually versioned files.
Use shorter caching for URLs that can serve different content later.
Change the filename when you need reliable cache invalidation.

The goal isn't to give everything a one-year cache because Lighthouse asked nicely.

The goal is to cache every file for as long as its URL structure safely allows.

Cloudflare and CDN caching

There is another layer involved if you're using Cloudflare or another CDN.

Your Nuxt route rules define headers at your application level.

But Cloudflare sits between your application and your users.

Depending on your configuration, Cloudflare may:

respect your origin caching headers,
apply its own caching rules,
decide that a response is not cacheable,
or override some of your settings.

So after deploying a caching change, don't just assume it worked.

Check the actual response.

For example:

curl -I "https://example.com/_ipx/q_80&s_640x360/projects/sharmarket.webp"

Look for:

cache-control

And if you're using Cloudflare, also look for headers such as:

cf-cache-status

This tells you much more than staring at your nuxt.config.ts and assuming everything between your server and the browser behaves exactly as expected.

Also check your Cloudflare Cache Rules and Workers if the headers you're receiving don't match what Nuxt is sending.

A practical default strategy

If you just want a reasonable starting point, this is how I think about it:

Hashed Nuxt build files

/_nuxt/**

Cache aggressively.

One year plus immutable makes sense because changing the content produces a different filename.

Versioned public files

Files like:

/logo.v4.png

can also be cached aggressively because you'll create a new URL when you replace them.

Normal public assets

Files such as:

/img/logo.png

should generally use shorter cache lifetimes unless you have a versioning strategy.

Several days or weeks is often enough.

Nuxt Image / IPX responses

/_ipx/**

can benefit significantly from caching, but I avoid marking them immutable unless the underlying image paths are also guaranteed to change when the source changes.

How to verify the setup

After deploying your changes:

Open your browser's developer tools.
Go to the Network tab.
Inspect one file under /_nuxt.
Inspect an original image from /img.
Inspect an optimized Nuxt Image request under /_ipx.
Check the Cache-Control response header for each one.
If you're using Cloudflare, inspect cf-cache-status.
Run Lighthouse again.

This is especially useful because the URL Lighthouse reports might not be the URL you expected.

That was the mistake in my case.

I was looking at my original images while Lighthouse was actually complaining about their transformed IPX versions.

FAQ

Is static file caching necessary on Vercel or similar platforms?

Yes, but you may not need to configure every part of it yourself.

Platforms like Vercel already handle many framework-generated assets efficiently, especially hashed build files.

That doesn't mean every URL in your application automatically receives the exact cache policy you want.

Things like public files, custom server routes, and generated image URLs such as /_ipx can still be worth checking.

The important thing is to inspect the actual response headers instead of assuming the hosting platform has already handled everything.

Shouldn't Nginx handle this?

It can.

If Nginx sits in front of your Nuxt application, you can absolutely configure caching headers there.

For example, you could define different policies for /_nuxt, /img, fonts, scripts, and other paths.

I personally prefer putting these rules inside Nuxt when possible because the caching policy then lives with the application.

If I move the application to another server or deployment platform, I don't have to remember that an important part of its behavior was hidden inside an Nginx configuration somewhere else.

But both approaches are valid.

I deploy with Coolify. Doesn't Coolify have options for this?

Coolify handles deployment and usually places a reverse proxy such as Traefik in front of your application.

That infrastructure can be configured to manipulate response headers, but it doesn't automatically know what caching policy makes sense for your application.

For example, it cannot magically know that your /_nuxt files are hashed while /img/logo.png may be replaced later under the same URL.

That's application-specific knowledge.

For me, defining the policy in Nuxt is simpler and makes the application more portable.

What if I want a specific file not to be cached?

You can create a more specific route rule.

For example:

routeRules: {
  '/img/**': {
    headers: {
      'cache-control': 'public,max-age=864000',
    },
  },

  '/img/dynamic-image.png': {
    headers: {
      'cache-control': 'no-store',
    },
  },
}

The specific route can override the broader one.

Use no-store when you genuinely don't want the response stored.

If you still want caching but want clients to revalidate the resource before using it, no-cache has a different meaning and may be more appropriate.

How can I purge a cached file when necessary?

This depends on where it has been cached.

If a CDN such as Cloudflare has the file, you can purge it from the CDN.

If you have another reverse proxy or server-side cache, that may also have its own invalidation mechanism.

The tricky part is the browser cache.

You generally cannot remotely force every user's browser to delete a file it has already cached.

That's why versioned URLs are so useful.

Instead of trying to make users forget:

/logo.png

you deploy:

/logo.v2.png

Now the browser sees a completely new URL and requests it normally.

For important static assets, URL versioning is often a much cleaner invalidation strategy than relying on cache purges.

Can I purge the Cloudflare cache?

Yes.

Cloudflare lets you purge cached resources from its dashboard, and it also exposes cache-purge APIs.

When possible, I prefer purging only the specific URL that changed rather than clearing the entire cache.

But remember: purging Cloudflare removes Cloudflare's cached copy.

It does not delete a file that a user's browser has already cached according to a long max-age or immutable policy.

Again, when immediate invalidation matters, changing the URL is usually the safest option.

Conclusion

Static file caching becomes much simpler once you stop treating every static-looking file the same way.

Nuxt's hashed build files can be cached for a very long time because every content change creates a new URL.

Files inside public/ require more care because their URL normally stays the same even if you replace the file.

Nuxt Image adds another layer because the optimized files requested by the browser live under /_ipx/**, which needs its own caching policy.

That last part was what I had missed in my own setup.

Once I separated those asset types and started thinking about caching based on whether the URL changes with the content, the whole thing became much easier to reason about.

And Lighthouse stopped complaining for the right reason — not because I blindly made every file immutable, but because the files were actually being cached according to how they behave.

Originally published on sadeq.dev.

How to Set Up Rate Limiting in Nuxt

Sadeq Sheikhi — Fri, 07 Aug 2026 00:23:06 +0000

Rate limiting is one of those things that doesn't feel urgent—until someone hammers your login endpoint at 3am and you wake up to a flooded database and a locked-out user base.

I added this to my Nuxt base layer after realising I'd shipped several projects with zero protection on auth routes. Not great.

This post walks through the exact setup I now use: Redis-backed, an in-memory fallback when Redis is down, named presets for different sensitivity levels, and a 429 page that shows a live countdown instead of just dying on the user.

The structure

Three pieces, each with one job:

createRateLimiter() — a factory that builds the limiter, using Redis with an in-memory fallback
applyRateLimit() — what you call inside handlers to enforce a limit
server/middleware/rateLimiter.ts — global middleware so every route gets a baseline for free

1. Install

npm install rate-limiter-flexible ioredis

rate-limiter-flexible does the heavy lifting: sliding windows, Redis integration, and the insurance fallback pattern we'll use.

2. The factory

Create server/utils/rateLimiter.ts:

import {
  RateLimiterRedis,
  RateLimiterMemory,
  type RateLimiterAbstract,
} from 'rate-limiter-flexible'

import { getRedisClient } from './redis'

export interface RateLimiterConfig {
  keyPrefix: string // Must be unique per limiter, e.g. 'rl:auth'
  limit: number // Maximum requests within the window
  windowSeconds: number
}

export interface RateLimitResult {
  allowed: boolean
  limit: number
  remaining: number
  resetAt: number // Unix timestamp in seconds when the window resets
  retryAfter: number // Seconds until retry; 0 if allowed
}

function buildLimiter(
  config: RateLimiterConfig,
): RateLimiterAbstract {
  const insurance = new RateLimiterMemory({
    keyPrefix: config.keyPrefix,
    points: config.limit,
    duration: config.windowSeconds,
  })

  const redis = getRedisClient()

  if (!redis) {
    return insurance
  }

  return new RateLimiterRedis({
    storeClient: redis,
    keyPrefix: config.keyPrefix,
    points: config.limit,
    duration: config.windowSeconds,
    insuranceLimiter: insurance, // Falls back to memory if Redis goes down
  })
}

export function createRateLimiter(
  config: RateLimiterConfig,
) {
  let limiter: RateLimiterAbstract | null = null

  function getLimiter(): RateLimiterAbstract {
    if (!limiter) {
      limiter = buildLimiter(config)
    }

    return limiter
  }

  return async function check(
    key: string,
  ): Promise<RateLimitResult> {
    try {
      const res = await getLimiter().consume(key)

      return {
        allowed: true,
        limit: config.limit,
        remaining: res.remainingPoints ?? 0,
        resetAt:
          Math.ceil(Date.now() / 1000) +
          Math.ceil((res.msBeforeNext ?? 0) / 1000),
        retryAfter: 0,
      }
    } catch (thrown: unknown) {
      // rate-limiter-flexible throws a RateLimiterRes object,
      // not an Error, when the limit is exceeded.
      //
      // If it throws something else, fail open. A broken limiter
      // should not block every user.
      const res = thrown as Record<string, unknown>

      if (typeof res?.msBeforeNext !== 'number') {
        console.error(
          '[rate-limiter] unexpected error:',
          thrown,
        )

        return {
          allowed: true,
          limit: config.limit,
          remaining: 0,
          resetAt: 0,
          retryAfter: 0,
        }
      }

      const retryAfter = Math.ceil(
        res.msBeforeNext / 1000,
      )

      return {
        allowed: false,
        limit: config.limit,
        remaining: 0,
        resetAt:
          Math.ceil(Date.now() / 1000) +
          retryAfter,
        retryAfter,
      }
    }
  }
}

Two things I want to highlight here:

Lazy initialization: the limiter builds itself on the first request, not at import time. This avoids initialization-order problems in environments where configuration or services may not be ready when modules are first loaded.

Fail open: when Redis throws something unexpected, the request goes through. I would rather have a temporarily unprotected endpoint than have a limiter bug take down the whole application for every user.

For an especially sensitive system, you may decide to fail closed instead.

3. Presets

Not all routes deserve the same treatment. A page view and a password-reset request are very different risks.

Add named presets at the bottom of the same file:

function env(
  name: string,
  fallback: number,
): number {
  const value = process.env[name]
  const parsed = value
    ? Number.parseInt(value, 10)
    : Number.NaN

  return Number.isFinite(parsed) && parsed > 0
    ? parsed
    : fallback
}

// 60 requests per minute — general API traffic
export const apiRateLimiter = createRateLimiter({
  keyPrefix: 'rl:api',
  limit: env('NUXT_RATE_LIMITER_API_LIMIT', 60),
  windowSeconds: env(
    'NUXT_RATE_LIMITER_API_WINDOW',
    60,
  ),
})

// 10 requests per 15 minutes — login, register, OTP
export const authRateLimiter = createRateLimiter({
  keyPrefix: 'rl:auth',
  limit: env('NUXT_RATE_LIMITER_AUTH_LIMIT', 10),
  windowSeconds: env(
    'NUXT_RATE_LIMITER_AUTH_WINDOW',
    15 * 60,
  ),
})

// 5 requests per hour — password reset, email verification
export const sensitiveRateLimiter =
  createRateLimiter({
    keyPrefix: 'rl:sensitive',
    limit: env(
      'NUXT_RATE_LIMITER_SENSITIVE_LIMIT',
      5,
    ),
    windowSeconds: env(
      'NUXT_RATE_LIMITER_SENSITIVE_WINDOW',
      60 * 60,
    ),
  })

// 200 requests per minute — SSR page routes
export const pageRateLimiter = createRateLimiter({
  keyPrefix: 'rl:page',
  limit: env('NUXT_RATE_LIMITER_PAGE_LIMIT', 200),
  windowSeconds: env(
    'NUXT_RATE_LIMITER_PAGE_WINDOW',
    60,
  ),
})

All limits are overridable through environment variables. You do not need to change the application code to tighten them in production.

4. The `applyRateLimit()` helper

Create server/utils/applyRateLimit.ts:

import type { H3Event } from 'h3'
import type { RateLimitResult } from './rateLimiter'

type LimiterFunction = (
  key: string,
) => Promise<RateLimitResult>

export function getClientIp(
  event: H3Event,
): string {
  return (
    getRequestHeader(event, 'cf-connecting-ip') ||
    getRequestHeader(event, 'x-real-ip') ||
    getRequestHeader(event, 'x-forwarded-for')
      ?.split(',')[0]
      ?.trim() ||
    'unknown'
  )
}

function setRateLimitHeaders(
  event: H3Event,
  result: RateLimitResult,
): void {
  setResponseHeader(
    event,
    'X-RateLimit-Limit',
    String(result.limit),
  )

  setResponseHeader(
    event,
    'X-RateLimit-Remaining',
    String(result.remaining),
  )

  setResponseHeader(
    event,
    'X-RateLimit-Reset',
    String(result.resetAt),
  )

  if (!result.allowed && result.retryAfter > 0) {
    setResponseHeader(
      event,
      'Retry-After',
      String(result.retryAfter),
    )
  }
}

export async function applyRateLimit(
  event: H3Event,
  limiter: LimiterFunction,
  keyFunction?: (event: H3Event) => string,
): Promise<void> {
  const bypassSecret =
    process.env.NUXT_RATE_LIMITER_BYPASS_SECRET

  const suppliedSecret = getRequestHeader(
    event,
    'x-rate-limit-bypass',
  )

  if (
    bypassSecret &&
    suppliedSecret === bypassSecret
  ) {
    return
  }

  const key = keyFunction
    ? keyFunction(event)
    : getClientIp(event)

  const result = await limiter(key)

  setRateLimitHeaders(event, result)

  if (!result.allowed) {
    throw createError({
      statusCode: 429,
      data: {
        code: 'RATE_LIMITED',
        retryAfter: result.retryAfter,
      },
    })
  }
}

The IP-resolution order matters when your Nuxt application is behind Cloudflare, nginx, or another reverse proxy.

event.node.req.socket.remoteAddress may contain only your proxy's IP, not the actual client's address. The helper checks common forwarding headers in priority order and falls back to 'unknown'.

Only trust these headers when requests can reach your application through infrastructure you control. Otherwise, clients may be able to spoof them.

The keyFunction parameter lets you limit requests using something other than an IP address when necessary.

5. Global middleware

Create server/middleware/rateLimiter.ts:

import {
  apiRateLimiter,
  pageRateLimiter,
} from '../utils/rateLimiter'

import { applyRateLimit } from '../utils/applyRateLimit'

const SKIP_PREFIXES = [
  '/_nuxt',
  '/__nuxt',
  '/api/_admin',
  '/_admin',
  '/img/',
  '/fonts/',
  '/js/',
  '/favicon',
  '/_ipx',
  '/robots.txt',
  '/sitemap',
  '/og-image',
]

export default defineEventHandler(async event => {
  const path = getRequestURL(event).pathname

  if (
    SKIP_PREFIXES.some(prefix =>
      path.startsWith(prefix),
    )
  ) {
    return
  }

  if (
    process.env.NUXT_RATE_LIMITER_ENABLED ===
    'false'
  ) {
    return
  }

  if (path.startsWith('/api/')) {
    await applyRateLimit(event, apiRateLimiter)
    return
  }

  if (
    event.method === 'GET' ||
    event.method === 'HEAD'
  ) {
    await applyRateLimit(event, pageRateLimiter)
  }
})

Every route now gets a baseline limit without touching its individual handler.

Static assets and Nuxt internals are skipped. Page limiting applies only to GET and HEAD requests.

6. Layering limits on sensitive routes

The global middleware is your floor. For sensitive endpoints, stack a second, tighter limit on top.

Both limits count down independently, so a request has to pass both.

// server/api/auth/login.post.ts

export default defineEventHandler(async event => {
  await applyRateLimit(
    event,
    authRateLimiter,
  )

  // Continue with authentication...
})

For password resets and similar endpoints, I key the limiter by email rather than IP.

An attacker can rotate IP addresses, but the target email remains the same:

// server/api/auth/reset-password.post.ts

export default defineEventHandler(async event => {
  const body = await readBody<{
    email: string
  }>(event)

  await applyRateLimit(
    event,
    sensitiveRateLimiter,
    () => body.email.trim().toLowerCase(),
  )

  // Continue with the password-reset flow...
})

You can also combine the email address and IP:

const email = body.email.trim().toLowerCase()
const ip = getClientIp(event)

await applyRateLimit(
  event,
  sensitiveRateLimiter,
  () => `${email}:${ip}`,
)

The correct key depends on what you are protecting.

7. The `429` page

Inside app/error.vue, pull retryAfter from the error data and show a countdown that reloads the page when it reaches zero:

<script setup lang="ts">
interface NuxtError {
  statusCode: number
  statusMessage?: string
  data?: {
    retryAfter?: number
  }
}

const props = defineProps<{
  error: NuxtError
}>()

const countdown = ref(
  props.error.data?.retryAfter ?? 0,
)

let interval:
  | ReturnType<typeof setInterval>
  | undefined

if (
  props.error.statusCode === 429 &&
  countdown.value > 0
) {
  interval = setInterval(() => {
    countdown.value -= 1

    if (countdown.value <= 0) {
      if (interval) {
        clearInterval(interval)
      }

      window.location.reload()
    }
  }, 1000)
}

onUnmounted(() => {
  if (interval) {
    clearInterval(interval)
  }
})

function retry(): void {
  window.location.reload()
}
</script>

<template>
  <main v-if="error.statusCode === 429">
    <h1>Too many requests</h1>

    <p v-if="countdown > 0">
      Retrying in {{ countdown }} seconds…
    </p>

    <button type="button" @click="retry">
      Retry now
    </button>
  </main>
</template>

There is nothing else the user needs to do. When the request window resets, the page reloads automatically.

8. Environment variables

# Set to "false" to disable rate limiting globally
NUXT_RATE_LIMITER_ENABLED=true

# Internal services can send this value through
# the x-rate-limit-bypass header
NUXT_RATE_LIMITER_BYPASS_SECRET=

# Redis configuration
# Leave the host empty to use the in-memory limiter
NUXT_REDIS_HOST=
NUXT_REDIS_PORT=6379
NUXT_REDIS_PASSWORD=

# General API preset
NUXT_RATE_LIMITER_API_LIMIT=60
NUXT_RATE_LIMITER_API_WINDOW=60

# Authentication preset
NUXT_RATE_LIMITER_AUTH_LIMIT=10
NUXT_RATE_LIMITER_AUTH_WINDOW=900

# Sensitive-action preset
NUXT_RATE_LIMITER_SENSITIVE_LIMIT=5
NUXT_RATE_LIMITER_SENSITIVE_WINDOW=3600

# Rendered-page preset
NUXT_RATE_LIMITER_PAGE_LIMIT=200
NUXT_RATE_LIMITER_PAGE_WINDOW=60

Summary

File	Responsibility
`server/utils/rateLimiter.ts`	Factory and named presets
`server/utils/applyRateLimit.ts`	Per-request enforcement, IP extraction, and headers
`server/middleware/rateLimiter.ts`	Global baseline protection
`app/error.vue`	`429` experience with countdown and automatic reload

The defaults here are conservative. Tune them according to your actual traffic.

The in-memory fallback means you can ship this before adding Redis and upgrade later without changing the API used throughout your application.

That is why I keep this implementation in my reusable Nuxt base layer: every new project starts with basic protection already available, instead of waiting until the first abusive request arrives.

I originally published this tutorial on my personal blog, where I write about Nuxt, TypeScript, infrastructure, and engineering decisions taken from real projects:

Read the original Nuxt rate-limiting article

DEV Community: Sadeq Sheikhi

Passkeys Explained: How Passwordless Authentication Works

What are passkeys?

The browser, authenticator, and server are different parts of the system

Your fingerprint is not your passkey

What exactly is stored inside a passkey?

What the server normally stores for a passkey

Credential IDs are important

What is an authenticator?

Platform authenticators

Roaming authenticators

What does the browser actually do?

How passkey registration works in detail

Attestation does not mean your server receives the private key

How passkey authentication works

Why the challenge matters

Why passkeys are resistant to phishing

What is the RP ID?

Discoverable credentials and username-less login

Synced passkeys versus device-bound credentials

What should the frontend do?

What should the backend do?

What about signature counters?

Metadata is part of the product experience, not just the protocol

Credential management deserves its own security rules

Recovery is part of passkey authentication

Can passkeys work on another computer?

Passkeys make authentication feel simpler because the complexity moved somewhere better

Static File Caching in Nuxt: An Easy and Practical Strategy

The simple caching rule

What the cache directives mean

The three main asset types in Nuxt

1. Nuxt build files: /_nuxt/**

2. Files inside public/

3. Nuxt Image files: /_ipx/**

The Nuxt route rules

Why the IPX rule matters

Do not use immutable everywhere

Cloudflare and CDN caching

A practical default strategy

Hashed Nuxt build files

Versioned public files

Normal public assets

Nuxt Image / IPX responses

How to verify the setup

FAQ

Is static file caching necessary on Vercel or similar platforms?

Shouldn't Nginx handle this?

I deploy with Coolify. Doesn't Coolify have options for this?

What if I want a specific file not to be cached?

How can I purge a cached file when necessary?

Can I purge the Cloudflare cache?

Conclusion

How to Set Up Rate Limiting in Nuxt

The structure

1. Install

2. The factory

3. Presets

4. The applyRateLimit() helper

5. Global middleware

6. Layering limits on sensitive routes

7. The 429 page

8. Environment variables

Summary

1. Nuxt build files: `/_nuxt/**`

2. Files inside `public/`

3. Nuxt Image files: `/_ipx/**`

Do not use `immutable` everywhere

4. The `applyRateLimit()` helper

7. The `429` page