Is Netlify Safe? Both Answers, For Developers and For Visitors

Netlify is safe to deploy on. Netlify's security page lists SOC 2 Type 2, ISO 27001, ISO 27018, PCI DSS v4.0 and HIPAA certifications, TLS 1.2 minimum with AES-256 encryption, and active DDoS mitigation. Whether a netlify.app link someone sent you is safe is a different question, and there the answer is no, not by default.

Two different people search this phrase. This page answers both, starting with the shorter answer.

If you were sent a netlify.app link

netlify.app is a free hosting subdomain. Anyone can sign up and deploy anything to it in about two minutes, with no review step before the site goes live. That includes real products, side projects, student work, and phishing pages built to look like a login screen for a service you use.

So the domain tells you nothing about trustworthiness. What it tells you is that the site was deployed on Netlify, which is a reputable host used by a very large number of legitimate companies.

Practical guidance:

• Never enter a password on a netlify.app URL for an account that lives somewhere else. A real service logs you in on its own domain.
• Never enter card details. A legitimate business that has reached the point of taking payments has a custom domain.
• Check who sent it. An unexpected link is the risk, not the hosting provider.
• A padlock in the address bar proves nothing about honesty. Netlify gives every deployment a free HTTPS certificate through Let's Encrypt, so phishing pages get the padlock too. It means the connection is encrypted, not that the site is honest.

If you run a site that is being flagged as unsafe, Netlify's own community forum carries threads about false positives on the shared subdomain. The dependable fix is a custom domain, because reputation then attaches to a name you control rather than one shared with every other free deployment.

The rest of this page is for the other searcher: the founder deciding whether to ship on Netlify.

What Netlify secures, according to Netlify

Netlify's security page documents the platform layer:

• Certifications including SOC 2 Type 2, ISO 27001, ISO 27018, PCI DSS v4.0 and HIPAA, with CCPA, GDPR and DORA compliance, and Netlify states it undergoes annual audits by independent third-party auditors
• All network traffic encrypted with a minimum of TLS 1.2 and AES-256, in transit and at rest
• Free HTTPS certificates through Let's Encrypt on every deployed domain, with the option to install your own
• Active DDoS mitigation covering layer 3 and 4 TCP attacks and layer 7
• A Web Application Firewall with customisable rules, Firewall Traffic Rules by IP address or geography, and rate limiting

Netlify is also unusually direct about the split. The same page states that application architecture and design, data handling, response caching configuration and authentication remain the customer's responsibility. That is an accurate description of where the problems in our scan data actually sit.

What we found in 17 Netlify-hosted apps

A caveat first, because it matters more here than on our other platform pages. We have scanned 17 apps on a netlify.app domain, out of 1,141 apps and 1,889 scans in Ubserve's production history, using the most recent scan of each app. That is a small sample, so these are counts rather than percentages, and you should read them as directional.

None of the 17 had a critical finding. The most serious issue that did appear was an exposed Google Maps API key, on 3 of them, which our scanner rates high because an unrestricted Maps key can be used by anyone who copies it, on your bill.

The interesting absence

One finding is missing from that table entirely: a wildcard CORS origin. It appeared on none of the 17.

Compare that to Vercel-hosted apps, where 79.6% had one, against a 25.1% baseline across everything else we scan. That is not because Netlify users are more careful. It is architectural. A Netlify site is more often a static build with no server routes at all, and you cannot misconfigure CORS on an API route that does not exist.

This is the single best argument for Netlify's security posture, and it deserves stating plainly: less code running on a server means less to get wrong. It also tells you exactly where to look the moment you do add server code.

Where the risk actually is on Netlify

1. Netlify Functions are public URLs

Every function you add is deployed to an address like /.netlify/functions/send-invoice. Anyone who reads your frontend bundle, or simply guesses a sensible name, can call it directly. Netlify does not put authentication in front of it. That is correct behaviour for a platform, and it means every function has to do its own checking.

A function that reads a database, sends email, or calls a paid API is the highest-value target on a Netlify site. Our Bolt.new security checklist covers the unprotected Netlify Functions that Bolt-generated apps commonly ship. The two checks it needs are the ones AI-generated functions most often skip: who is calling, and whether that caller owns the thing they asked for.

// netlify/functions/get-invoice.js
export default async (req) => {
  const token = req.headers.get("authorization")?.replace("Bearer ", "");
  const user = token ? await verifySession(token) : null;
  if (!user) return new Response("Unauthorized", { status: 401 });

  const id = new URL(req.url).searchParams.get("id");
  // The ownership check lives in the query, not in the frontend.
  const invoice = await db.invoices.findFirst({ where: { id, ownerId: user.id } });
  if (!invoice) return new Response("Not found", { status: 404 });

  return Response.json(invoice);
};

Functions that call paid services need a third check: a rate limit. An unauthenticated function that wraps an AI or SMS API is a way for strangers to spend your money, and Netlify's own rate limiting rules exist for exactly this.

2. Build-time environment variables

This is the one that leaks keys. Frontend build tools expose some variables to the browser on purpose, based on a prefix: VITE_ in Vite, NEXT_PUBLIC_ in Next.js, REACT_APP_ in Create React App. Anything with one of those prefixes is compiled into the JavaScript bundle every visitor downloads.

Netlify is behaving correctly when this happens. The variable was requested for the browser. But the consequence is permanent: once a build carrying that key has been deployed, the key is public and rotating it is the only remedy. If that has already happened, our guide on what to do when an API key is exposed covers the order to do it in.

Netlify gives you one control most founders never touch. Netlify's environment variable settings let you scope a value to specific deploy contexts. A production database key does not need to exist in every deploy preview built from every pull request, and scoping it removes that copy entirely.

3. Deploy previews and branch deploys

Each pull request can produce a full, working copy of your site at its own URL. If that preview carries production secrets and a function that uses them, you now have a second copy of your backend that nobody is watching and that was built from code nobody has merged yet.

Give previews test credentials, not production ones. If a preview can reach real customer data, restrict who can open it rather than relying on the URL being hard to guess.

4. Proxy rewrites in _redirects

A redirect rule with a 200 status does not redirect. It proxies the request to another origin and returns the response from your domain. That is useful, and it is also the easiest way to publish something that was never meant to be public:

# _redirects
/api/*   https://internal-admin.example.com/:splat   200

Anyone can now reach that internal service through your public domain, without whatever network restriction protected it before. Review every 200 rule and ask whether the destination was designed to face the internet.

5. Security headers, which Netlify makes easy

Fourteen of the 17 were missing at least one security header, which matches the pattern across our whole dataset, where 70.1% of all 1,141 apps are missing one. On Netlify this is a configuration change rather than a code change, using either a _headers file in your publish directory or netlify.toml, both described in Netlify's custom headers documentation:

# _headers
/*
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Content-Security-Policy: default-src 'self'; img-src 'self' data: https:; script-src 'self'

Treat that Content-Security-Policy as a starting point to tighten, not a finished policy, since a strict CSP will break third-party scripts until you allow them explicitly. Then verify it is being served:

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

6. Form submissions

Netlify Forms accept a submission from anyone who posts to them. Spam filtering helps with volume, but it does not make the content safe. If submissions flow into an admin panel, an email template, or a function, treat every field as untrusted input: escape it before rendering, and never pass it straight into a query.

7. Your database, if you have one

Four of the 17 apps shipped a Supabase anon key, and three had a table a logged-out request could read. That is not a Netlify problem. It is the same Row Level Security problem that dominates every stack we scan, and Netlify's static architecture does nothing to prevent it because the database is reached directly from the browser. Is Supabase safe has the two-minute test and the table names we find open most often. If your data lives in Firebase instead, the equivalent protection is your Firebase Security Rules.

8. Build logs

Deploy logs record everything your build prints. A build script that logs its configuration, or a debugging line like console.log(process.env) left behind by an AI agent, writes secret values into a log that everyone on the team can read and that tends to outlive the line that produced it.

Search your build scripts and framework config for anything that prints environment variables before your next deploy, and rotate any value that has already appeared in a log. Removing the line stops the next leak. It does not un-publish the last one.

9. Edge Functions used as a gate

Edge Functions run before a request reaches your page, which makes them a natural place to put a login check. The failure is in the path matching. A gate that protects /dashboard but not /dashboard-export, or not the function that serves the dashboard's data, leaves the data reachable by anyone who asks for it directly.

Protect data at the point it is served, inside the function or the database, and treat an edge check as an extra layer rather than the only one.

So is Netlify safe for your app?

• Static marketing site or docs? Yes, with very little to think about. Add the headers file and a custom domain.
• Static frontend plus a few functions? Yes. Every risk you have lives inside those functions and your environment variables, so audit those specifically.
• Full application with auth and a database? Yes, and Netlify's certifications will satisfy a procurement questionnaire. They say nothing about whether your functions check ownership or your tables have policies.
• Regulated data? Netlify states HIPAA and PCI DSS v4.0 compliance. Your own obligations are unchanged, and the customer-responsibility list on Netlify's security page is the part an auditor will ask you about.

If someone else built your site

If a contractor, a template or an AI tool set up your Netlify site, you can still answer the important question without reading any code. Ask for three lists:

• Every function, and what each one does with data or money.
• Every environment variable, and which deploy contexts can read it.
• Every rule in _redirects or netlify.toml with a 200 status, and where it points.

Those three lists cover the places this page says the risk actually lives. Anything on them that nobody can explain is the first thing to check, and usually the first thing to remove.

A fifteen-minute Netlify check

1. Functions. List everything in your functions folder and call each one with no auth header. Anything that returns data or does work needs a session check and an ownership check.
2. Bundle. Open DevTools and search the loaded JavaScript for AIza, sk_ and service_role. A match is public and needs rotating.
3. Variable scopes. In your site settings, confirm production secrets are not available to deploy previews.
4. Previews. Open a recent deploy preview in a private window and check what it can reach.
5. Rewrites. Search _redirects and netlify.toml for 200 rules and confirm each destination is meant to be public.
6. Headers. Run the curl command above.
7. Database. If you use Supabase, run the logged-out table test from our Supabase guide.

The verdict

Netlify is a safe host with an unusually honest description of where its responsibility ends. Its static-first architecture removes a whole category of mistake that affects most apps on server-rendered platforms, and our data shows that as a measurable difference rather than a marketing claim: zero wildcard CORS findings in 17 apps.

What is left for you is small and specific: the functions you add, the keys your build inlines, the previews you leave open, and the rewrites you point at other services. Work through the pre-deploy security checklist before launch, and what Ubserve checks for lists the full set of issues behind the numbers on this page.