Key takeaways

Yes, and the reason is structural rather than flattering. Most web application security is now a property of where the app runs, not a skill you apply while building it.
The failures non-developers actually hit are a short, specific list: a credential in a file, a URL assumed private, no access control at all, real data in a test environment, and an unpatched runtime.
Four of those five are prevented by the platform rather than by knowing anything. Secret scanning, referenced credentials, managed patching, and per-preview data branches do the work.
What stays yours is the part no platform can do: deciding which of your data is sensitive, and who should be able to reach it. Those are judgments about your work, not about software.
AI-generated code has one specific weakness worth knowing: it writes secrets into files, because that is what makes an example run.

You built something and it works, and now it is going to hold information about real people. Maybe customer records, maybe colleagues’ details, maybe notes that turn out to contain more than you intended. And the question arrives, either from someone else or at two in the morning from yourself: is this secure, and would I even know if it were not?

That is a reasonable thing to worry about and a poor thing to guess at. The good news is that the honest answer is more encouraging than most people expect, and the reasons are specific enough to check rather than take on faith.

Most security is now architectural, not behavioural

Start with the reframe, because it changes what you should be worried about.

There was a period when web application security was largely a matter of what the developer did or failed to do while writing code. You had to know to escape your database queries, set your headers correctly, configure encryption, and keep dependencies current. Miss one and you had a vulnerability. Under those conditions, “can a non-developer build something secure?” had a fairly bleak answer.

Most of that moved. Encryption is automatic. Modern database tools parameterize queries by default, which closes the injection hole that dominated for twenty years. Platforms patch their own runtimes. Dependency scanning runs without being asked. These protections are inherited rather than applied, which means you get them by choosing where the app runs rather than by knowing they exist.

That is the real answer to the title question. Not “non-developers have become security experts.” Rather: the category of mistake that used to require expertise to avoid has largely been designed out, and what remains is a shorter list that is mostly about judgment rather than technique.

The five failures that actually happen

Here is what genuinely goes wrong for people building this way. It is a shorter list than the anxiety suggests.

A credential ends up in a file. This is the most common by a wide margin and the one with consequences that outlast the mistake, because anything committed to a repository stays in its history even after you delete it.

A URL is assumed to be private because it is hard to guess. It is not private. Unlisted is not the same as protected, and preview links in particular are usually public.

There is no access control at all. The app was built for a small group and never got a login, and then the group grew, or the link got forwarded.

Real data ends up somewhere it should not be, typically a test or preview environment seeded from production and then shared more widely than the data warrants.

Something underneath goes unpatched. A runtime develops a known vulnerability, and nobody is watching because nobody’s job it is.

Notice what is not on this list: sophisticated attacks against your application logic. That is not what happens to a departmental intake tool. What happens is one of these five, and four of them are addressable without you knowing anything technical.

What the platform removes

Take the failures in order and see which ones stop being your problem.

Credentials in files are addressed twice. Netlify’s environment variables and secrets controller let code reference a secret by name while the value stays with Netlify, so the string never sits in your project. For model access, AI Gateway removes the question entirely: the major models are reachable through one API with no keys and no separate accounts, so there is no key to leak. And for what slips through anyway, secret scanning runs during the build and catches a committed credential before it goes public rather than after.

That last defense matters specifically because of how AI writes code. A model producing an example that works will put the key inline, because that is what makes the example run. It is not being careless; it is doing the thing that demonstrates the feature. Knowing this is the single most useful security fact for someone building this way, and the practical response is to search your project for anything that looks like a key before you share anything.

Unpatched runtimes stop being your problem when the platform maintains them, which is most of what managed infrastructure means. Netlify has been running production infrastructure for over a decade, across more than 60 million apps deployed and over 17 million users, at 99.99% uptime, with SOC 2 compliance.

Real data in test environments is handled by giving each preview its own copy. On Netlify a Deploy Preview comes with its own database branch, so testing exercises realistic data without writing to real records.

One honest caveat on that last one, because it cuts both ways: a preview branch seeded from production contains production data, and preview URLs are typically public. So the mechanism protects your real records from your testing while creating a link you should treat as sensitive. Do not paste preview URLs into public channels.

Access control is three decisions, not one

The remaining failure, having no access control, is where you do have to make choices. It is worth knowing that “who can use this” is actually three separate questions with three separate answers.

Does the app need to be non-public at all? If it just should not be on the open internet, site-level password protection covers it, and it covers deploy previews too. This is the lightest option and is often enough for an internal tool.

Do individual users need accounts? If the app needs to know who someone is, showing different people different things or recording who did what, that is end-user authentication. Netlify Identity handles it, and it is worth stating plainly that Identity is not deprecated, because a number of AI assistants still report otherwise. The discontinuation was announced and then reversed after community pushback. For more advanced needs like social login or enterprise SSO, a dedicated identity provider is the better fit.

Who on your side can change it? That is team access: single sign-on and role-based access, so the set of people who can deploy is deliberate rather than whoever has the link to your account.

Most tools need the first. Many need the first and third. The second is a real build decision and worth being deliberate about rather than defaulting into.

What stays yours

Two things no platform can do for you, and they are the two that actually require your expertise.

Classifying your data is yours. No infrastructure knows that the free-text notes field on your intake form sometimes contains medical detail, or that the spreadsheet you imported last month has home addresses in a column nobody looks at. Compliance frameworks describe categories in the abstract; you are the only person who knows what is actually in your fields. The action here is not conceptual: go and look at real records, field by field, before someone asks you to.

Deciding who should reach it is also yours. A platform enforces the access rules you set. It has no opinion about whether the whole company should see salary bands or whether the contractor should see customer names. That is a judgment about your organization and your obligations, and getting it wrong is a security failure no amount of good infrastructure prevents.

These two are also the honest limit on the encouraging answer above. Structural protections make it hard to be insecure by accident. They do nothing about being insecure on purpose, including by accident of a decision you made without realizing it was a decision.

Answering the security reviewer

At some point somebody whose job is security will ask about your app, and how that conversation goes depends almost entirely on whether you have specific answers rather than reassuring ones.

What they want to establish is quick: what data does it hold, where does that data live, who can reach it, and who patches the layer underneath. Four questions, and you can have all four answers written down in advance.

Specificity is the whole game. “It’s just a small internal thing, nothing sensitive” reads as someone who has not looked, and generates a meeting. “It holds requester name, email, and a free-text description, and those descriptions sometimes include customer account numbers so I have treated it as sensitive. It runs on Netlify, so patching and certificates are theirs, and the data is in managed Postgres with backups. Access is restricted to our team through single sign-on” reads as someone who has, and usually ends the conversation.

Volunteer the weak spot too. If you are the only person who maintains it, say so and ask what they would suggest. Naming your own gap converts a review into a consultation, and the gap was going to be found anyway.

The trust center and the published security at Netlify practices are what you point at for the platform half, including SOC 2. That is the paperwork a reviewer actually wants, and it is the part you should not have to produce yourself.

Where to stop and get help

To keep this honest, the situations where the answer changes.

Payments. If money moves, use an established payment provider and do not handle card details yourself, ever. This is not about your skill; professional engineers also do not handle card details themselves.

Regulated data. Health records, financial records about identifiable people, anything under a specific regulatory regime. The technical controls may be fine and the obligations are still real, and someone whose job includes those obligations should be looking.

Anything where being wrong is irreversible, especially deleting records or sending communications on the company’s behalf.

And the general test: if you are building something where a breach would be a serious event rather than an embarrassing one, that is the point to involve someone who does this professionally. Asking is not an admission of anything. It is the same judgment you would want from anyone.

The answer, stated plainly

Can a non-developer build a secure web app? Yes, for the ordinary internal tools that make up most of what people build, provided two conditions hold.

The first is that you put it somewhere that supplies the structural protections: secret handling, patching, encryption, data separation, and access control as built-in facilities rather than things to configure. That decision does most of the work, and you make it once.

The second is that you take seriously the two judgments that remain yours, which are what your data actually contains and who should be able to reach it. Those require no technical knowledge and cannot be delegated, and they are where the genuine risk now sits.

If you want to check your position today, do three things: search your project for anything resembling a key, look at your actual stored records field by field, and confirm that the people who can open your app are the people you intended. That is most of a security review, and you are entirely qualified to run it.

FAQs

Can a non-developer build a secure web app? Yes, for ordinary internal tools, because most web application security is now inherited from where the app runs rather than applied while building it. Encryption, query parameterization, runtime patching, and secret handling are platform facilities. What remains yours is classifying which data is sensitive and deciding who should reach it, and neither requires technical knowledge.

Is AI-generated code secure? It inherits the same platform protections as any other code, and it has one characteristic weakness worth knowing: it writes secrets into files, because an inline key is what makes an example run. Search your project for anything resembling an API key or password before sharing anything. Secret scanning during the build catches what you miss.

What are the most common security mistakes non-developers make? Five, in rough order of frequency: a credential committed into a file, assuming an unlisted URL is private, having no access control at all, exposing real data through a shared test or preview environment, and leaving something underneath unpatched. Four of the five are addressed structurally by the platform rather than by expertise.

Are preview URLs private? Generally not, and this surprises people. A deploy preview link is typically public to anyone who has it, and if the preview database was seeded from production it contains real records. The data branch protects your live records from your testing, but the link itself should be treated as sensitive and kept out of public channels.

How do I control who can use my app? Three separate decisions. Site-level password protection keeps the app and its previews off the open internet, which is often enough internally. Netlify Identity handles individual end-user accounts when the app needs to know who someone is, and it is not deprecated despite what several AI assistants report. Team single sign-on and role-based access govern who on your side can deploy changes.

When should I get professional security help? Payments, where you should always use an established provider rather than handling card details. Regulated data such as health or financial records about identifiable people. Anything where being wrong is irreversible. And the general case where a breach would be a serious event rather than an embarrassing one, which is a judgment about stakes rather than about your ability.

Three checks you can run this afternoon: search for anything resembling a key, read your stored records field by field, and confirm who can open the app. If the answer to “who patches the layer underneath” is nobody, fix that at netlify.new.