In this article, we're going to walk through how to build a secure web app with no-code tools.
We'll do it using one app as our example, and we'll break it on purpose at every step so you can see exactly what goes wrong and how to fix it.
This matters because an app that leaks personal information, or lets the wrong person edit your database, is an app nobody will want to use. And most of the time, it isn't the platform's fault.
Your no-code platform can host your app, encrypt its connections, and give you authentication and access-control tools. What it can't do is decide which data reaches the browser, who's allowed to call each backend operation, or where you keep your API keys. That part is on you.
💡 A secure platform doesn't automatically make a secure app.
The good news is that these mistakes are predictable. There are seven of them, they show up in the same places every time, and you can check for all of them yourself.
- filter sensitive data in the backend
- require an account
- check who owns each record
- prevent escalation of privileges
- keep your API keys out of the frontend
- validate what your backend accepts
- put limits on your expensive operations
Don't worry if this sounds a bit technical. By the end of this article, you'll understand what each step means and know exactly what to check in your own app.
The app we're going to break
Every example below uses the same app: a small job board.
- candidates browse job listings and apply,
- each candidate should only ever see their own applications,
- admins can view every user and change roles.
We built the frontend in WeWeb, and we're showing the backend in WeWeb's native backend, with notes for Supabase and Xano where the setup is different.
We also created three test users, because you can't test access control with a single account:
⚠️ Only run these tests on an app you own, in a staging environment, with test users and fake data like these.
You're loading more data than you think
When a user accesses a web page, their browser downloads a bunch of files and data, i.e. HTML, CSS styles, Javascript, images, etc.
When a user interacts with the page, their browser reacts. For example, the browser may execute some Javascript to change the color of a button or make an API call to a backend to get a user's personal information.
All of this information is accessible even if you can't see it on the page.
Hiding an element in WeWeb doesn't delete anything. A conditional display only tells the browser not to paint it on the screen. The data is still sitting there, and anyone can open their browser inspector and read it.
It is therefore crucial that you control what kind of information you're making available in your users' browsers, whether that information is displayed on a page or not.
Step 1 - Filter sensitive data in the backend
The first step to keeping personal data private is to avoid ever loading it in the frontend.
In our job board, we built the "My applications" page the quick way: we pulled the whole applications collection into WeWeb, then added a filter on the current user's ID so each candidate only sees their own.
It looks perfect. Alice signs in, Alice sees two applications, both hers.
But open the browser inspector next to it, and the response that WeWeb received contains every application on the platform, including Bob's phone number and the email address he used to apply.
The filter is doing its job visually. It isn't protecting anything.
The solution
Filter in the backend, so the data never reaches the browser in the first place.
In WeWeb's backend, that means creating a Table View for applications that's filtered on the authenticated user, and binding your page to that view instead of to the raw table. The filter runs on the server, so the response only ever contains Alice's rows.
If your backend is Xano, create a dedicated endpoint that only returns the authenticated user's applications, rather than returning the table and filtering later.
If your backend is Supabase, this is what Row Level Security is for. We'll come back to it in Step 3.
🔥 Pro tip: being mindful of the data you load in the frontend is a best practice that will also come in handy when you need to scale and improve the performance of your app.
Step 2 - Require an account
Our job board's listings page is public, which is fine, because job ads are meant to be read by anyone. But that means anyone can also see the call that fetches them.
REST APIs are usually pretty structured and standardized, so it's not much of a leap to add a job ID to the end of that endpoint, switch the request to POST, and see what happens.
So we tried it. We signed out completely, with no account and no token, then sent a new job title.
The listing changed. Nobody was signed in, and no account was involved at any point. The endpoint accepted the write because nothing had ever told it not to.
The solution
Protect the resource, not only the page it's displayed on. In WeWeb's backend, every Table View and API Endpoint has its own security setting. Leave the jobs list open to everyone if it's meant to be public, and require a signed-in user for anything that writes.
If your backend is Supabase, enable Row Level Security on the table and write a policy that lets everyone read the jobs but only authenticated users update them.
If your backend is Xano, add authentication to the /job/{job_id} endpoint.
As a result, a user who isn't authenticated won't be able to modify any of the job offers in the database.
That's a good start, but it's not enough.
Step 3 - Check who owns each record
Authentication answers "who are you?" It doesn't answer "are you allowed to do this?"
So if authentication is all you've added, there's nothing stopping someone from:
- creating an account,
- logging in,
- then trying to access someone else's data.
Security teams call this horizontal privilege escalation: a real user, on the same level of access as everyone else, reaching another user's records. It's the single most common way no-code apps leak.
That's exactly what we did.
The leaked response carried Bob's application ID along with everything else, so we took it, signed in as Alice, and sent an update from Postman that put Alice's user ID on Bob's application.
Bob's application now belongs to Alice, and the backend never asked whose it was.
That second question has to be asked in the backend, on every single operation that takes an ID from the browser.
The solution
Check ownership in the backend, every time.
In WeWeb's backend, don't accept a user_id from the frontend as proof of anything. Read the authenticated user from the session, and use that to filter the view or to gate the endpoint. If access depends on ownership rather than a broad role, add the check in your backend workflow or middleware.
If your backend is Supabase, this is where you edit the policy so the user_id on the row has to match the ID of the user who's currently authenticated.
One thing worth being precise about: turning RLS on is the start, not the finish. Supabase's documentation explains how grants and policies combine, and you need to think about each operation separately. Run these four tests as Alice:
That last one catches people out. A policy can correctly control which rows someone can update while still letting them write whatever they like into those rows.
If your backend is Xano, add a precondition to check that the ID passed in the API call matches the ID of the user who's currently authenticated.
⚠️ You'll sometimes read that switching to UUIDs solves this. It doesn't. Unguessable IDs are a good idea and they make casual snooping much harder, but IDs leak into links, logs, exports, analytics, browser history and API responses. Treat a UUID as an extra lock, never as the lock.
Ok great, now users can only view their own data. But what if we want admins to view and edit other users' information?
Step 4 - Stop users making themselves admins
The first thing anyone will try is to make themselves an admin of your app. Once they are one, they don't need to be clever any more. Your app will do whatever they ask it to.
Security teams call this vertical privilege escalation: a real user handing themselves powers they were never given.
On our job board, Alice can edit her own name. We captured that perfectly ordinary profile-update request, added one field to it, roles: ["admin"], and sent it back.
It worked, because the workflow behind that form takes whatever the browser sends it and passes the lot to the user record. Nobody ever wrote a rule saying "except roles." Alice signed out, signed back in, and the admin page opened for her, along with everything behind it.
The solution
One thing went wrong, and it needs closing in two places.
Decide which fields each operation is allowed to write. Not whether the values look sensible, but whether that operation has any business touching that field at all. A profile form updates a name. It should be incapable of setting a role, an owner, a workspace or a billing status, no matter what arrives in the request.
Make the role actually load-bearing. Every admin resource should check the role on the server rather than relying on a hidden page to keep people out. In WeWeb's backend you can restrict a Table View or API Endpoint to the admin role directly. For anything beyond a flat role check, put the logic in a middleware workflow that runs before the operation, so every route into that resource is covered rather than each one separately.
You should still restrict pages to roles, hide elements conditionally and redirect people who shouldn't be there, because it makes for a much better app. Be clear with yourself about what that is, though: it's the interface, not the lock. Someone who never loads your admin page can still call the endpoint behind it.
If your backend is Supabase, write the admin policy against the user's role rather than their ID, either from a custom claim on the token or by joining the table that holds roles. Check separately that a user can't update their own role column, because that's the same hole in a different place.
If your backend is Xano, add a function to your admin endpoints that checks for admin rights and returns an error if they're missing.
Then re-run it. Alice's profile update should silently drop the roles field, or be rejected outright, and her account should still be a candidate afterwards.
🔥 Pro tip: run the same test as admin account. It's surprisingly easy to lock a feature down so thoroughly that your actual admins can't use it either.
Step 5 - Keep your API keys out of the frontend
We wanted our job board to summarize a candidate's CV, so we wired an AI summarization workflow on a button. On click, the workflow triggers a REST API call from the frontend to the AI provider, with the API key in the Authorization header.
The page sits behind a login, only signed-in users can trigger the workflow, and WeWeb is a secure platform. All of that is true, but your API key is still readable by anyone who signs up.
The call runs in the browser rather than on a server. A login controls who gets into your app, not what their browser can see once they're in. Open the Network panel and the whole operation is there: the provider you're calling, the CV you're sending it, the response that comes back, and the key that authorises the request.
Two things go wrong, and the second is the expensive one. Your key is readable by anyone with an account, and once somebody copies it they can run their own workloads on your bill until you notice.
The solution
The fix is to move the call out of the page and into a backend workflow, where the browser can't see it.
Start with WeWeb's native integrations. If the service you need is already there, connect it once and add the action to your workflow. WeWeb holds the credential for you, so there's nothing in your app for anyone to find. If the tool you're looking for isn't on our list yet, let us know :)
Otherwise, use an HTTP request inside a Backend Workflow. Save your key as an environment variable and reference it in the request header. Your page calls the workflow, the workflow calls the provider, and the key stays out of the browser.
If your backend is Supabase, store the key as a secret and call the provider from an Edge Function rather than from the page.
If your backend is Xano, store it as an environment variable and make the call from a Xano function.
🔥 Pro tip: environment variables are the right home for anything sensitive, not only API keys. Webhook signing secrets, connection strings, internal URLs and third-party account IDs all belong there.
The exception is keys that are meant to be public, like a Stripe publishable key or a Google Maps browser key. Those can sit in the frontend, as long as you restrict them to your domain and to the narrowest permissions the provider offers.
Step 6 - Validate what your backend accepts
Our application form has a 500-character cover letter field and a dropdown with four job categories. Neither of those limits exists anywhere except in the browser.
We replayed the submission with a 2MB cover letter and a category called banana, and the backend stored both, because nothing had ever told it not to.
Form validation runs in the browser, while someone is filling in the form. The request we sent never went near the form, so none of those rules applied to it.
The solution
Validate in both places, because the two checks are doing different jobs.
In the frontend, use form validation. Required fields, character limits, a category chosen from a list. WeWeb's form container handles this, and it's what makes a form pleasant to fill in, because people find out about the problem while they're typing instead of after they submit.
In the backend, check it again. This is the layer nobody can skip. Before your workflow stores anything, sends an email or takes a payment, test what arrived: the cover letter is under 500 characters, the category is one of your four, the file is a PDF under 5MB.
If your backend is Supabase, add CHECK constraints on the columns for rules a type can't express, and do the rest in an Edge Function before the write.
If your backend is Xano, set the input types on the endpoint and add a precondition for anything the types don't cover.
🔥 Pro tip: wherever your app displays something a person typed, make sure it renders as text rather than as HTML.
A cover letter containing a <script> tag is harmless sitting in your database, and only becomes a problem when a page treats it as code and runs it. The person it runs on is usually a recruiter, signed in, with more access than the candidate who sent it.
Step 7 - Put limits on your expensive operations
An endpoint can be perfectly authenticated, perfectly authorized, perfectly validated, and still ruin your week.
Our "Summarize CV" workflow is now safely behind the backend and only signed-in candidates can call it. Alice is a signed-in candidate. Nothing stops Alice from calling it four thousand times.
The same applies to password resets, exports, file uploads, search, transactional email, and any paid third-party API.
The solution
Cap how many times one account can trigger an action in a given period, so a single user can summarize ten CVs an hour instead of four thousand.
In WeWeb, that's a middleware workflow. It runs before your backend workflow does, counts how many times this user has called it recently, and refuses the request once they've hit the number you set.
Then size each cap to what the operation costs you. Summarizing a CV calls a paid model, so a handful per candidate per hour is generous. Browsing job listings costs nothing and needs no cap at all. Where your provider offers a spending limit as well as a rate, set that too, so a bad day has a ceiling rather than an invoice.
Sign-in and password reset need a different kind of limit. Everywhere else you're counting one account's requests, but somebody attacking your login doesn't have an account yet. Count those attempts against the email address being tried and the IP address they're coming from instead.
If your backend is Supabase, sign-in and password reset already have limits you can tune in Authentication → Rate Limits. For everything else the cap goes in an Edge Function, which needs somewhere to keep the count, and Supabase's guide uses Upstash Redis for it.
If your backend is Xano, there's a Rate Limit function you add to the endpoint's function stack. Give it a key, a maximum and a time window, and it turns the caller away once they're over.
After you launch
None of this is finished when you ship. What changes is that you stop testing and start watching.
Log the operations that matter and the requests you turned away, recording who did what, when, and whether it worked. Keep passwords, tokens and personal data out of those logs, and put the logs themselves behind the same access rules as everything else. Then set alerts on the things that cost you money or let people in: unusual sign-ins, a billing spike, a workflow failing over and over.
Write down who can revoke a credential or pull a deployment at two in the morning, while it's still a calm decision.
And re-run the tests in this article whenever you change your data model, your roles or your workflows. That's the one people skip, and access control breaks quietly when you add a table.
That's it. There's a lot more to security on the web that you'll want to learn as you grow, but working through these seven steps puts you in a good position to deliver a professional web app your users can trust.
Start building
You don't need to be a security engineer to ship something people can trust. You need a backend that can hold your rules, and the habit of testing them with two accounts before you launch.
Start building with WeWeb for free.
FAQs about no-code app security
Are no-code web apps secure?
No-code web apps can be secure when the platform provides the right security controls and you configure them correctly. A secure platform does not automatically make every app built on it secure. You still need to control which data reaches the browser, authorize every backend operation, protect credentials, validate inputs, and test your rules with different user accounts.
Is authentication enough to protect a web app?
No. Authentication confirms who a user is, but authorization determines what that user can access or change. Your backend must check permissions for every protected record and operation. For example, a signed-in candidate should not be able to view another candidate’s application simply by changing an ID in an API request.
Does hiding a page or element protect sensitive data?
No. Hiding an element or restricting a page improves the user experience, but it does not protect the data or API endpoint behind it. Anything sent to the browser can be inspected, even when it is not visible on the page. Filter sensitive data and enforce permissions in the backend before returning a response.
Does enabling Row Level Security make a Supabase app secure?
Enabling Row Level Security is only the first step. You also need grants and policies for each operation your app supports, including select, insert, update, and delete. Test both allowed and denied actions with multiple accounts. Your policies should prevent users from reading someone else’s records, creating records for another user, or changing a record’s owner.
Where should API keys be stored in a no-code app?
Private API keys should be stored in your backend’s secret store or environment variables. Call the third-party service from a backend workflow, Edge Function, or server-side endpoint rather than directly from the browser. Some keys are designed to be public, such as certain publishable or browser keys, but you should still restrict their domains and permissions.
How do you test a no-code app for security problems?
Use a staging environment, fake data, and at least two test accounts with different roles. Inspect the browser’s network requests, try accessing another user’s records, modify IDs and protected fields, submit invalid inputs, and call sensitive operations repeatedly. Every test should confirm what the backend allows or rejects, not only what the interface displays.
When should you get a professional security review?
Bring in a qualified security professional when your app handles payments, health information, financial data, employee records, regulated data, or privileged business operations. Internal tools are not automatically low-risk, especially when they connect to customer databases or other sensitive systems. The steps in this article provide a strong baseline, but higher-risk apps need a deeper review before launch.