Is Netlify safe? As a host, yes: Netlify documents SOC 2 Type 2 and ISO 27001, managed TLS and DDoS mitigation. Whether your site is safe on it is a separate question, because the settings that leak data belong to you: Function authentication, response headers, environment-variable scopes, Forms, redirect rules and who can open a Deploy Preview.

Is Netlify safe? What the platform secures and what you configure

Netlify’s platform covers the infrastructure: certified operations, managed TLS, DDoS mitigation and isolated builds. The project half is yours: response headers, Function authentication, rate limits, variable scopes, Forms spam controls, redirect rules and preview access, and many of those controls stay open until someone sets them.

Netlify draws the same line itself. Netlify’s security page says customers are responsible for the security of their applications, including application architecture, data handling, response caching and authentication, while Netlify manages the security of the infrastructure. The split works the same way on other hosts, and the answer on whether Vercel is safe follows it too.

The table pairs each platform control with the project setting that still sits with you.

Netlify platform controlThe project setting you still own
Certifications: SOC 2 Type 2, ISO 27001, ISO 27018, PCI DSS, HIPAANone to set: they describe how Netlify runs Netlify
Managed TLS, minimum TLS 1.2, free Let’s Encrypt certificatesHSTS and a CAA record on your custom domain
DDoS mitigation at layers 3, 4 and 7Abuse limits on your own routes, in code
Web application firewall (Enterprise with High-Performance Edge; “Limited” on Free, Personal and Pro)Whether your plan has it
Isolated builds on temporary virtual machinesWhat your build scripts print and bundle
Masking of sensitive variable values in deploy logsReading the first deploy log in full
Secrets Controller (listed on every plan)Marking each secret variable as secret
Variable scopes and deploy contexts (every scope and context by default; scopes on Pro and Enterprise)Narrowing each variable
Preview protection: project visibility, password on Pro and EnterpriseTurning it on for previews
Two-factor authentication on every plan; team SAML SSO on EnterpriseEnforcing them for every member

Netlify docs read on 21 October 2026. Netlify’s security checklist separates the two halves in the same way: one part lists built-in platform protections, the other lists measures it recommends your team set, from 2FA and SSO to a Content Security Policy. The same pattern of insecure defaults on managed platforms shows up well beyond Netlify, and a founder still picking a host can compare Railway vs Vercel, Netlify and Fly.io before committing.

Are Netlify Functions protected by default?

Netlify Functions are not protected by default: a Function answers anyone who calls its path, and Netlify cannot know whether a route should be public. Authentication belongs inside the Function, and rate limits are written as code-based rules, which Netlify documents on all plans.

A Function is a file of server-side code; it receives a Request, returns a Response, and its config object sets the URL path it runs on. Netlify’s Functions overview states no built-in access check, so the check is the first thing the code does. The example below refuses a request with no credential and adds a code-based limit in the shape Netlify’s rate limiting docs give.

// netlify/functions/export.mts
import type { Config, Context } from "@netlify/functions";

export default async (req: Request, context: Context) => {
  const auth = req.headers.get("authorization");
  if (!auth?.startsWith("Bearer ")) {
    return new Response("Unauthorized", { status: 401 });
  }
  // A header that exists proves nothing. Validate the token with your
  // identity provider and load the user before returning any data.
  return Response.json({ ok: true });
};

export const config: Config = {
  path: "/api/export",
  rateLimit: { windowLimit: 100, windowSize: 60, aggregateBy: ["ip", "domain"] },
};

The limit numbers are Netlify’s own example, 100 requests in 60 seconds per IP; a request over it gets a 429. Code-based rules are capped at two per project on Free and Personal and five on Pro, and enforcement can lag by up to 10 seconds after a client crosses the threshold. One detail catches people out: a rule that fails validation does not fail the deploy, so the deploy log is where you confirm the rule was read. Choosing the numbers for login, signup and AI routes, and testing them, is covered in where a rate limit goes.

We audited 21 third-party AI-built apps in June and July 2026, and in 10 of them the server trusted the client: it accepted whatever the browser asserted. Those apps are a selected set, not a random sample, and nobody picked them by host, so the count says nothing about Netlify’s own failure rate.

If the site takes payments or holds customer data and nobody has yet called its Functions logged out, as another user, or in a rapid burst, that is the point to bring in someone from outside the build: a free audit is where we weigh up with you which Functions carry that risk and which one to test first. In the Production Hardening Sprint, deliverable 3.6, Public-endpoint rate limits, is verified this way: simulate bursts and verify enforcement without blocking ordinary use.

Netlify security headers are set in your project

Netlify security headers are set in the project, through a _headers file in the publish directory or a netlify.toml block. Netlify documents the format; it cannot choose a Content Security Policy for scripts and APIs it does not know, so the policy is tested on a preview first.

Netlify’s headers docs describe both places: a plain text file named _headers saved to the publish directory, or one or more headers tables in the Netlify configuration file. The same page carries a limit that matters for apps: custom headers apply only to files Netlify serves from its own store, so a response from a Function, an Edge Function or a server-rendered page must set its own headers.

A starting shape for a static site, never a policy to copy as is:

/*
  Content-Security-Policy: default-src 'self'
  Strict-Transport-Security: max-age=300
  Referrer-Policy: strict-origin-when-cross-origin
  X-Content-Type-Options: nosniff

default-src is the fallback for the other fetch directives, so default-src 'self' alone blocks scripts, images, fonts and API calls from any other origin. Deploy it to a preview first and run login, checkout and any embeds before it reaches production. We’d keep HSTS at a short max-age like the five minutes above while testing and raise it once nothing breaks, because a browser keeps an HSTS policy until it expires, even after the header is removed, and includeSubDomains extends it to every subdomain. Writing a policy that keeps inline scripts working is the subject of a content security policy without unsafe inline.

Where environment variables end up on Netlify

Netlify stores environment variables set in its UI, CLI or API outside the repository, but a value the build writes into the client bundle ships to every visitor. A variable applies to every scope and deploy context unless narrowed, so a production secret set once also reaches every Deploy Preview build.

Netlify recommends the UI, CLI or API over netlify.toml so that sensitive values stay out of the repository. Each variable can hold a different value per deploy context (production, Deploy Previews, branch deploys, local development), and on Pro and Enterprise plans it can be limited to scopes such as Builds or Functions. By default it is available to all scopes and carries the same value everywhere, which is how a live payment key ends up in a preview build nobody meant to trust with it.

Netlify’s Secrets Controller adds a stricter policy for variables you flag with “Contains secret values”: the value becomes write-only, and Netlify scans repository code and build output for it, failing the build and naming the location in the deploy log if it turns up. The pricing page lists it on every plan, Free included. Keeping development, staging and production keys apart is a wider job, covered under one set of keys for every environment.

Build-time values ship in the bundle

A value the framework writes into client code is a string in a file every visitor downloads. Vite exposes variables prefixed VITE_ in client-side source code after bundling and warns that they should not contain sensitive information such as API keys. Next.js inlines NEXT_PUBLIC_ variables into the JavaScript sent to the browser at build time, and the built app no longer responds to later changes to them.

So rotating the dashboard entry does not un-ship a value already built. Rotate the credential at its provider, then delete the deploys that contain the old one; Netlify’s checklist notes you can delete a deploy yourself even though logs are masked. Netlify masks sensitive values it detects in deploy logs, but your own scripts decide what else gets printed, so read the first deploy log of a new project in full.

Netlify Forms and redirect rules are public by design

Two Netlify features answer requests from anyone on the internet, whatever page they came from.

Netlify Forms accept posts from anywhere

Netlify’s Forms setup docs say a JavaScript-rendered form can be submitted with a POST request to any path on your site, so a script can send submissions without ever loading your page. Every submission is filtered for spam with Akismet, and a honeypot field, a reCAPTCHA 2, or both are opt-in extras, as Netlify’s spam filter docs describe.

Submissions sit in the site’s Forms tab, and links to uploaded files appear in the Netlify app, in email notifications, in CSV exports and through the API. The spam filter page does not say which team roles can read them, so check who on the team can open the Forms tab and where notifications are sent. A form that sends email or calls a paid API is also a cost problem that spam filtering will not cap. Rate limits, honeypots and other controls for bots submitting a signup form have their own write-up.

A caller-chosen redirect is an open redirect

Netlify’s redirect rules are fine when the destination host is fixed. Netlify’s own proxy example, /api/* https://api.example.com/:splat 200, keeps the host fixed and only passes the path through. The risk starts when code takes the destination from the request, usually a next or to parameter in a Function:

// netlify/functions/go.mts
// Open redirect, never ship: Response.redirect(url.searchParams.get("next"), 302)
import type { Config } from "@netlify/functions";

const ALLOWED = new Map([
  ["docs", "https://docs.example.com/"],
  ["status", "https://status.example.com/"],
]);

export default async (req: Request) => {
  const target = ALLOWED.get(new URL(req.url).searchParams.get("to") ?? "");
  if (!target) return new Response("Unknown destination", { status: 400 });
  return Response.redirect(target, 302);
};

export const config: Config = { path: "/go" };

A caller-chosen destination sends visitors anywhere with your domain at the start of the link, which is exactly what a phishing page wants. The fix is a fixed list of keys mapped to full URLs, as above. A fetch whose target host comes from a query parameter is the server-side version of the same mistake, known as server-side request forgery. Both, with the other classes an AI builder tends to leave in, are explained in the vulnerability classes an AI builder leaves behind. As we read it, an open redirect is also one way a legitimate site can end up with a browser warning on its own domain.

Who can open a Netlify Deploy Preview

When a pull request opens in a connected repository, Netlify builds a Deploy Preview automatically and serves it at its own unique URL. What protects that URL depends on the plan, as Netlify’s password protection docs set out.

On credit-based Free, Personal and Pro plans, the setting is project visibility: public, password or private, applied to production and previews or to previews only. Password protection is not available on credit-based Free and Personal plans, where the way to restrict a project is to make it private, which on those plans means visible only to the Team Owner. Enterprise, Open Source and legacy plans keep the older Password Protection settings, with basic password protection and team login protection.

Visibility is only half of it. A preview wired to the production database is production under another hostname, whoever can see it. Keeping preview deployments with test data is the other half.

Is Netlify free and safe for client sites?

Netlify’s Free plan is safe in the security sense, since it runs on the same managed TLS, DDoS mitigation and isolated builds. Its risk is availability: a hard limit of 300 credits a month with no way to buy more, after which every project is paused.

Netlify is actually free in the plain sense: the pricing page lists a Free plan with a 300-credit monthly limit, and its FAQ says the free plan cannot exceed those limits or incur costs. How Netlify credits work adds what the limit means: Free has a hard limit, buying more credits is an option for Personal and Pro plans, and once the balance is used up, all web projects are paused and visitors find a “Site not available” page at each project’s URL. The balance resets at the start of each cycle.

That makes the Netlify free hosting limits an outage risk rather than a breach risk: a launch, a mention on a busy forum or a bot crawl can take a client site offline until the reset or an upgrade. Who owns the account decides who can recover it. An agency that hosts every client under one account has one credit pool, so one busy site can pause all of them. Credit pauses on other builders and hosts are compared in what each builder stops when credits run out.

Is Netlify trustworthy? What the SOC 2 report and the review scores measure

Netlify can be trusted with hosting on the evidence it publishes: SOC 2 Type 2 and ISO 27001 reports on how Netlify runs its own platform. Public review scores and third-party security ratings measure other things, customer experience and the netlify.com domain, and neither says anything about your app.

The Netlify SOC 2 report sits in Netlify’s Trust Center: its security page says Enterprise customers can access audit reports there, including the SOC 2 Type 2 attestation, while all customers can view the ISO 27001 certificate online. A SOC 2 Type 2 report covers the provider’s own controls over time. It never covers the customer’s app, its Functions or its settings.

On Trustpilot, the public review page for Netlify showed a TrustScore of 1.9 from 79 reviews on 21 October 2026. What those reviews say is for each reader to weigh. UpGuard publishes a security rating for Netlify and says it is based on the analysis of Netlify’s external attack surface. That grades the outside of netlify.com, one thing, and none of it reaches the sites customers deploy.

What to check before launching on Netlify

Each check below is something you can run and fail, which makes it a managed platform hardening checklist for one Netlify project.

  1. 01 Open each Deploy Preview and branch URL in a private window, logged out
  2. 02 Call each Function logged out, as an ordinary user and as another customer's user, and confirm it refuses or returns nothing that is not theirs
  3. 03 Send a burst at login, signup, email, export and AI routes, wait a few seconds for counting, and confirm the limit answers with a 429
  4. 04 Search the built JavaScript for the first characters of each secret value
  5. 05 Deploy the headers to a preview and run login, checkout and uploads with the browser console open
  6. 06 Read every redirect and proxy rule, and every Function that redirects, for a destination a caller controls
  7. 07 Turn on a honeypot or reCAPTCHA on every form and list who on the team can read submissions
  8. 08 Enforce two-factor authentication on the Netlify team and remove people who have left

Item 8 is the same rule that applies to two-factor authentication on every provider dashboard; Netlify’s checklist recommends 2FA and enforced SSO for the team. These checks sit in the release path described in DevOps for startups.

In the Production Hardening Sprint, three of these surfaces have written verify steps: deliverable 2.9, Managed-platform security settings, is verified by recording the before-and-after settings for each managed service, naming each risky default and its new value ; deliverable 3.4, Production security headers, by inspecting response headers and exercising the application to confirm intended protections without broken flows ; and deliverable 7.7, Pull-request previews, by opening a preview from a test pull request and verifying its environment isolation. Hosting, paid tools and API usage are paid through your accounts.

Common questions about Netlify security

What are the downsides of using Netlify?

For security, the main downsides are plan tiers and the Free plan’s hard stop: the full web application firewall needs an Enterprise plan with High-Performance Edge (the pricing page marks it “Limited” on Free, Personal and Pro), password protection is not available on credit-based Free and Personal plans, and when a Free account uses its 300 monthly credits every project pauses until the balance resets. The project settings, from Function checks to headers, are the owner’s work on every plan.

Which hosting site is the most secure?

No host makes an app secure on its own. A host’s certifications describe how it runs its own platform, which for Netlify means SOC 2 Type 2 and ISO 27001 among others, while the settings that leak data, such as access rules, keys, headers and previews, sit in the project on any host.

Is Netlify Forms free?

Yes on Netlify’s credit-based plans: Netlify lists form submissions there as unlimited and free. Accounts still on legacy plans are metered by usage, and their free tier has a submission limit.

Is Netlify free forever?

The Free plan is priced at “$0 forever” on Netlify’s pricing page, and Netlify says the free plan is always free, with hard monthly limits that cannot be exceeded or incur costs. The catch is availability: once the monthly credits run out, every project on the account pauses until the balance resets or the account moves to a paid plan.

When should I get help securing a site hosted on Netlify?

Get help before the site takes payments or stores customer data, if nobody has yet tested its Functions, previews and variables the way an outsider would. AxonBuild offers a free audit, with no code access needed, where we talk through with you which of those settings matter most before launch.