Is Vercel Safe? What We Found in 102 Vercel-Hosted Apps

Vercel is safe to deploy on. It holds a SOC 2 Type 2 attestation and ISO 27001:2013 certification, encrypts data at rest with AES-256, and mitigates DDoS traffic automatically on every plan. Your app is the part that is usually not safe. Across 102 Vercel-hosted apps we scanned, 84.3% had at least one high or critical finding.

What we found scanning 102 Vercel-hosted apps

These numbers come from Ubserve's own production scan history: 1,889 scans across 1,141 distinct apps, taking the most recent scan for each app. 102 of those apps were served from a vercel.app hostname, which is how we can separate them from the rest.

One caveat worth stating plainly: apps still on a default vercel.app domain skew earlier-stage, because most teams move to a custom domain before launch. Read this as a snapshot of Vercel-hosted projects, not a verdict on every company that uses Vercel.

The headline is the CORS row. A wildcard CORS origin turned up on 79.6% of Vercel-hosted apps against 25.1% of everything else we scan, which is over three times the rate. That is the one number that makes Vercel deployments genuinely different, and it is not something Vercel does to you. For contrast, none of the 17 Netlify-hosted apps we scanned had one.

What Vercel secures, according to Vercel

Vercel's security page documents the platform layer:

• A SOC 2 Type 2 attestation and ISO 27001:2013 certification, with HIPAA support for enterprise customers and PCI DSS v4.0 SAQ-D and SAQ-A Attestations of Compliance
• Data encrypted at rest with AES-256 and in transit over HTTPS and TLS
• Automatic DDoS mitigation on all plans, plus a Web Application Firewall with custom rules for logging, blocking, challenging, and rate limiting
• Deployment Protection on all plans, with password protection on Pro and Enterprise
• BotID for bot detection without CAPTCHAs

That list is real and it is more than most teams would build themselves. It also has nothing to do with whether a logged-out visitor can read your database.

Platform incidents on the record

Vercel publishes security bulletins, and three are worth knowing if you are evaluating the platform:

• April 19, 2026. Vercel disclosed an incident it describes as unauthorized access to certain internal Vercel systems. The bulletin page does not set out the scope, so treat the dated disclosure as the fact and check the page for current status rather than relying on secondhand summaries.
• December 26, 2025. A bulletin covering CVE-2025-55184 and CVE-2025-55183.
• June 29, 2026. The React2Shell bulletin covering CVE-2025-55182.

The last two matter for a reason worth separating out: they are React and Next.js vulnerabilities, not Vercel infrastructure vulnerabilities. They would affect a Next.js app wherever it runs. Patching your framework version is your job on any host, and it is the one item on this page that a platform certification genuinely cannot cover for you.

The five failures we actually see on Vercel apps

1. A wildcard CORS origin (79.6% of apps)

This is the defining Vercel finding. An Access-Control-Allow-Origin: * response header on an API route means any website can call that route from a visitor's browser. On its own with no credentials it is often survivable. Combined with a route that returns user data based on a session, it is not.

The severe version is rarer but worse: two of the 102 apps reflected the requesting origin back while also allowing credentials, which lets an attacker's page make authenticated requests as your logged-in user. One allowed a wildcard origin together with credentials.

Check what your routes actually send before assuming the framework handled it:

curl -s -I -H "Origin: https://attacker.example" https://your-app.vercel.app/api/me \
  | grep -i "access-control-allow"

If that prints access-control-allow-origin: * or echoes back https://attacker.example alongside access-control-allow-credentials: true, fix it before anything else on this page.

2. No rate limiting observed (64.1%)

Nearly two thirds of Vercel-hosted apps showed no sign of rate limiting on login, signup, or reset routes. Vercel's WAF can do this for you with custom rules, and it is one of the few items on this list you can fix in the dashboard rather than in code.

3. Auth pages that browsers are allowed to cache (46.6%)

Almost half served login or password reset pages without cache controls that prevent storage. On a shared or synced browser profile, that puts an authenticated page into someone else's history.

4. JWTs in browser storage (13.6%)

At 13.6% against 6.1% elsewhere, Vercel-hosted apps were more than twice as likely to keep a session token in localStorage, where any successful script injection can read it. Cookies with HttpOnly cannot be read by scripts. This usually arrives as a default in an auth example rather than a decision anyone made.

5. A preview hostname serving production traffic (9.7%)

This one is Vercel-only. We saw it on 9.7% of Vercel-hosted apps and on exactly 0% of everything else, because the pattern cannot exist anywhere else. Our scanner flags it when the x-vercel-id header is present and the hostname matches a preview-style deployment URL, meaning something like myapp-k2j4h8s9.vercel.app is being handed to real users as the canonical address.

It is not a breach by itself. It does reveal your deployment topology, it splits your SEO signal across hostnames, and it usually means nobody has configured a production domain yet, which tends to correlate with the rest of this list.

6. Missing security headers (78.4% missing a high-severity one)

Security headers are the most common finding in our entire dataset, across every platform: 70.1% of all 1,141 apps we have scanned are missing at least one. Vercel-hosted apps are slightly worse at the severe end, with 78.4% missing a high-severity header against 67.3% everywhere else.

The one that matters most is Content-Security-Policy, because it is the control that limits the damage when a script injection does land. It is also the one that takes real thought to configure, which is why it is usually the one left out. A Next.js app can set these in next.config.ts headers or in middleware, and the checks take seconds to confirm:

curl -s -I https://your-app.com | grep -iE "content-security-policy|strict-transport-security|x-content-type-options|referrer-policy"

Email your domain cannot prove it sent

Half of the Vercel-hosted apps we scanned had no DMARC record (51.5%) and no SPF record (51.5%), against 25.6% and 22.4% elsewhere. That is twice the rate, and the explanation is mundane: a project still on a vercel.app hostname usually has not set up domain email yet.

It is not an application vulnerability. It does mean anyone can send mail that appears to come from your domain, which matters the moment you send a password reset or an invoice.

What Vercel-hosted apps do better

One row in that table runs the other way. Vercel-hosted apps were missing subresource integrity on 6.8% of scans against 24.5% everywhere else, a roughly 3.5x better result.

The reason is architectural rather than virtuous. Next.js bundles and serves its own assets from the same origin instead of pulling libraries from third-party CDNs at runtime, so there are fewer external scripts that need an integrity hash in the first place. It is a genuine reduction in supply-chain surface, and it is the clearest case on this page of the platform's defaults helping you without being asked.

Why there are so few critical findings, and what they were

Here is where our data disagrees with most Vercel security content. The usual warning is that you will leak an admin credential. On Vercel, that is rare.

Of 102 Vercel-hosted apps, the critical findings broke down as:

• 3 apps with a Supabase table readable by an unauthenticated request
• 2 apps reflecting the request origin while allowing credentials
• 1 app each with a service-role-style key label, a Postgres connection string, a wildcard CORS origin with credentials, a table with RLS disabled, an exposed debug endpoint, an exposed OpenAI key, and an exposed Supabase anon key flagged as critical in context

So exactly one of 102 apps exposed something that looks like a service-role key. The critical problems were access control, not secret management. If you are deciding where to spend an afternoon, spend it on who can read your data rather than on rotating keys.

The NEXT_PUBLIC_ trap

Next.js documents the behaviour precisely: non-prefixed environment variables are only available in the Node.js environment, while prefixing a variable with NEXT_PUBLIC_ tells Next.js to inline the value, at build time, into the JavaScript bundle delivered to the client. The docs also note those values are frozen at build time.

That is the mechanism behind most leaked keys in Next.js apps on Vercel. Nothing is misconfigured. Someone needed a value in a client component, added the prefix because the error message suggested it, and shipped the key to every visitor.

Two practical consequences:

• A key that must stay secret cannot be used in a client component. Move the call into a route handler or a server action and keep the variable unprefixed.
• For the secrets that stay server-side, Vercel's Sensitive Environment Variables make a value non-readable once created, available in preview and production, and redacted from build logs when the value is 32 characters or longer. Vercel always redacts VERCEL_AUTOMATION_BYPASS_SECRET and VERCEL_OIDC_TOKEN. Team owners can enforce this for all new production and preview variables.

If you have already shipped a key to the browser, rotating it is the only fix, and our guide on what to do when an API key is exposed covers the order to do it in.

Deployment Protection is not application auth

Deployment Protection restricts who can load a deployment URL. It is the right tool for keeping preview builds away from the public. It is the wrong tool for deciding which logged-in user may read which record.

If you are shipping a real product, you need both:

• Deployment Protection so preview deployments are not publicly indexable or reachable
• Authorization inside every route handler and server action, checking not just that a session exists but that this session owns the resource being requested

An app that passes Deployment Protection and fails the second check is exactly the shape of the three apps in our data whose database tables answered unauthenticated requests.

So is Vercel safe for your app?

• Building a prototype or internal tool? Yes, with no caveats worth acting on. Set a production domain and move on.
• Shipping a SaaS with real users and a database? Yes, but the platform covers none of your actual risk. Work the CORS header, rate limits, session storage, and per-record authorization, in that order.
• Handling health, financial, or other regulated data? Yes at the platform level, since Vercel supports HIPAA for enterprise customers and holds the PCI attestations above. Your obligations are unchanged, and a compliance auditor will look at your authorization logic, not Vercel's certificate.
• Deploying AI-generated code you have not read line by line? Treat every item in this article as unverified until you have checked it. The failures above are defaults, and AI tools reproduce defaults faithfully. Is Cursor safe covers why AI-written code breaks this way.

Verify your own deploy in ten minutes

1. CORS. Run the curl command above against your two or three most sensitive API routes. A wildcard or a reflected origin is the first thing to fix.
2. Public bundle. Open DevTools, search the loaded JavaScript for eyJ, sk_, and service_role. Anything that matches is public, permanently, and needs rotating.
3. Session storage. In the Application tab, check localStorage for a token. Move it to an HttpOnly cookie if it is there.
4. Auth page caching. curl -I https://your-app.com/login | grep -i cache-control should prevent storage.
5. Hostname. If users reach you on a hash-style *.vercel.app URL, configure a production domain.
6. Database authorization. If you use Supabase, confirm Row Level Security is on and the policies are scoped to the requesting user. Start with the tables we most often find open. Our Supabase security checklist walks the 15 checks in order, and if you are hitting policy errors already, why Supabase RLS stops working covers the common causes.
7. Rate limits. Add WAF rules on login, signup, and reset.

Work through the pre-deploy checklist if you would rather run one pass over everything, and what Ubserve checks for lists the full set of issues behind the numbers in this article.

The verdict

Vercel is one of the safest places to put a Next.js app and one of the easiest places to deploy an unsafe one. The platform is certified, encrypted, and DDoS-protected by default. The application on top of it fails at a measurably higher rate than the rest of what we scan, and it fails on one thing above all: 79.6% of Vercel-hosted apps answer any origin that asks.

That is a header, not an architecture. It is an afternoon of work. Most of the 84.3% can be moved out of that bucket by someone who has read this far. For the broader pattern behind these numbers, how vibe-coded apps get hacked sets out what goes wrong across every platform we scan.