Web Developer Security Tips for Next.js Apps (2026)

In 2026 your coding agent can write a working login form and a working hole in the same afternoon. Security write-ups this year keep saying the same uncomfortable thing: the time from a disclosed bug to an exploit is shrinking, and a lot of new software is “vibe coded” into production. The developer tip is not “never use AI.” It is “assume the patch is hostile until the gate says otherwise.”

I am Vishvajeet Shukla. These are the checks I run on Next.js and Node apps before they see a custom domain. They are boring on purpose. Boring is what keeps a Jaipur SME off a leak screenshot.

Related: GA4 setup · vitals.

Tip 1: Secrets live in env, not in the repo, not in the prompt history

Service account JSON, OpenAI keys, and Firebase private keys do not belong in git log. They also do not belong in a chat you cannot delete. Use env on the server. Rotate anything that was ever pasted into a ticket. The most common helpful agent constraint in a 2026 GitHub study was still “never commit secrets.” Write it down. Enforce it with a pre-commit scan if your team keeps slipping.

Tip 2: Auth on every mutating route

Agents love to scaffold app/api/posts/route.ts and forget the cookie check. I grep for Route Handlers and ask: who can POST? If the answer is “anyone with the URL,” that is not an MVP. That is an open form for spam and a write hole. Admin CMS routes need a real session, not a hidden URL.

Tip 3: Dependencies are part of the threat model

Run npm audit in CI. Do not click “audit fix force” because an agent suggested it. Read the breaking change. Agent-written lockfiles pull transitive packages you have never heard of. Weekly audit is the floor; money and personal data deserve a real scanner. 2026 AppSec pieces are pushing agentic scanners in the IDE and in CI — use them if you can afford the noise, but do not skip the floor.

Tip 4: Rate-limit anything an LLM or a form can hit

Public /api/chat, /api/contact, and login POSTs will be probed. A handful of requests per IP per hour is enough for a real visitor and enough to stop someone using your key as free compute. Log 429s. I have watched a “tiny” chatbot route become the largest line item on a bill.

Tip 5: Do not trust the model with policy

Never let an agent decide who is an admin. Never let it disable CSRF “to fix the test.” Never let it serve user HTML without escaping. If a test is hard, fix the test. Do not delete the guard. Attackers use coding assistants too; they are good at turning a new CVE into a request you did not expect.

A Friday 20-minute audit

1. git grep for sk-, BEGIN PRIVATE KEY, and AIza.
2. List app/api/**/route.ts and mark each as public or auth’d.
3. Confirm .env* is gitignored and not uploaded to the host’s public folder.
4. Hit login and contact 30 times; confirm you get blocked.
5. Read the last agent PR for deleted middleware.

If you cannot explain who is allowed to call an endpoint, the endpoint is not finished.

Headers, cookies, and the boring middle

Set cookies HttpOnly and Secure in production. Do not store JWTs in localStorage because a tutorial from 2019 did. If the agent adds a new cookie, ask whether JavaScript needs to read it. Almost never. SameSite lax is a reasonable default for a marketing site with a small admin.

Turn on HTTPS redirects at the host. HSTS is fine once you are sure you will not need to go back to HTTP for a forgotten subdomain. Mixed content on a Cloudinary image is usually a typo in the URL, not a reason to disable the browser padlock.

Uploads: allow a short list of mime types, cap size, and do not trust the filename. An agent will happily write an uploader that saves ../../../.env. Use a generated object name on S3 or Cloudinary. Never serve user uploads from the same origin as the admin cookie if you can avoid it.

What I tell clients

A fast Next.js marketing site still needs HTTPS, a locked admin, and backups. Security is not a premium theme. It is why we do not put Firebase admin keys in the Next bundle “because it was easier.” The same discipline as performance work: measure, then change one thing.

If you handle payments or health data, stop after this article and hire someone who does that for a living. This is a public blog, not a pentest.

Public marketing sites are still targets

People say “it’s only a brochure.” Brochure sites get spam in the contact form, scraped emails, and the occasional injected script through a forgotten WordPress leftover. A Next.js rebuild removed that leftover — until someone copied an old HTML snippet into a CMS field. Sanitize rich text. Do not render raw HTML from Firestore unless you trust the author account, and even then prefer a tight allow-list.

Admin on the same domain as the marketing site is convenient and risky. At minimum, do not share the session cookie with a wide path if you do not need to. Log admin logins. Disable unused signup if the CMS is only you.

FAQ

Is Vercel enough security?

It is a good host. It does not know you left signup open. That is your code.

Should I put security headers on every page?

Yes: at least nosniff and a sensible referrer policy. Do not copy a 40-line CSP you do not understand; you will break your own analytics.

Can an agent replace a security review?

It can find missing awaits and obvious XSS. It cannot replace a person who knows your threat model. Use both.

What about Firebase rules?

If the client talks to Firestore, rules are the real auth. A pretty login screen with open reads is not auth. Test rules with a logged-out request.

Where do I start this weekend?

Secrets grep, then API auth, then rate limits. In that order. New features after.

Next step

If you want a pass on a Next.js + Firebase app, send the public URL and whether users can write to the database from the browser. I will tell you the first hole I would close.

Contact · [email protected] · More guides