Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Neon’s Data API can let a browser application read and write PostgreSQL data without a custom application server in the request path. That does not eliminate the backend’s security responsibilities: authentication, SQL privileges, row-level security (RLS), and carefully reviewed database functions still have to work together. A DevOps Daily Team case study reports that its task-board demo rejected 27 hostile requests, but the result applies to that implementation and test suite—not to every Neon project or every RLS policy.
What “no backend” means in this design
Neon’s Data API provides a REST interface over a Neon branch database and is described by Neon as PostgREST-compatible. Its API reference identifies two authentication options: built-in Neon Auth or an external JWT provider configured with a JWKS URL. In either case, the design sends signed identity information toward PostgreSQL, where database roles, grants, and policies determine what the caller can do.
Removing a custom application server therefore changes where the application boundary sits; it does not remove that boundary. With a direct API, database configuration is exposed more directly to hostile clients. A server can provide an additional place to validate requests or implement application logic, but it is not a substitute for correct database permissions if it connects with an overpowered role.
Keep three separate questions in view: did the request establish a caller’s identity; do that role’s SQL privileges allow the requested operation and columns; and, for a role subject to RLS, does policy allow access to the particular rows? Neon also uses “Neon RLS” as a product term; Neon’s announcement explicitly distinguishes it from PostgreSQL Row-Level Security.
#1 Best Overall
What the 27 attacks tested—and what they did not
In a September 25, 2026 article, DevOps Daily Team describes a multi-tenant task board built with static frontend files, Neon Auth, the Neon Data API, PostgreSQL grants and policies, and a database function. The team reports that its harness rejected 27 hostile cases: 25 cross-tenant attempts by another organization’s owner and two attempts by a user with the wrong role inside the target organization.
The reported attempts included crafted filters, embedded joins, aggregate counts, forged-token attempts, bulk updates, and upserts using another tenant’s identifiers. The team says its harness checked expected responses and compared victim-row columns before and after each attempt. These are reported results from one application’s test harness, not an independent audit or proof that Neon, or any arbitrary RLS configuration, is secure.
Break tests exposed distinct failure modes
The same article reports four deliberate failure configurations, with three triggering the expected attacks:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →- Disabling RLS on a comments table exposed rows and allowed an in-tenant role violation.
- A SECURITY DEFINER summary function without a tenant filter leaked a summary.
- A permissive insert check combined with broad table-wide grants allowed a cross-tenant insert.
- A weak
WITH CHECK (true)policy by itself did not enable the tested cross-tenant insert when column-level grants prevented clients from setting the tenant field.
That last result illustrates defense in depth in this specific test; it does not establish that column grants generally compensate for a flawed policy. Grants and policies must each be reviewed as part of the complete permission model.
How PostgreSQL RLS actually limits access
PostgreSQL’s version 18 documentation describes RLS as an additional layer to SQL privileges: grants determine whether a role can use a table or column, while policies constrain which rows normal queries and data-modification commands can return or affect. A client needs the necessary SQL privilege as well as an applicable policy permitting the row-level action.
Enable it deliberately and check who can bypass it
Tables have no RLS policies by default. After RLS is enabled, if no policy permits an operation, normal row access is denied. However, table owners typically bypass policies unless the table is forced subject to RLS; superusers and roles with the BYPASSRLS attribute also bypass them. Check the effective database role used by the API, not just whether a policy appears in the schema.
Understand policy expressions and composition
USING controls which existing rows a command may see or target. WITH CHECK constrains rows an insert or update would produce; in applicable cases, PostgreSQL uses a matching WITH CHECK expression when one is omitted. Policy expressions are evaluated per row, and a row is not allowed when the expression is not true.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Permissive policies combine with OR, while restrictive policies combine with AND. Adding a permissive policy can therefore widen access even if another policy looks narrow. Review the full policy set for each table and command rather than assessing one policy in isolation.
Where a direct API and a custom server put the work
This is an architectural distinction, not a guarantee that either design is safer. The exact boundaries depend on the roles, code, and policies a project configures.
| Review question | Direct Data API | Custom application server |
|---|---|---|
| Where is caller identity established? | By the configured authentication path, such as Neon Auth or a JWT provider; verify how that identity reaches the database role and policies. | By the server’s authentication path; verify what identity or role it passes to the database. |
| Where is authorization enforced? | SQL grants and RLS policies are directly central to data access; review any exposed functions separately. | Server-side checks may mediate requests, while database grants and RLS still govern the server’s database access. |
| Who can change the boundary? | Anyone with authority to alter API configuration, roles, grants, policies, or functions can change the exposed data boundary. | Those database authorities remain important, alongside whoever can change server code and deployment configuration. |
| What happens after membership changes? | Check token lifetime and whether policies consult current membership; an already issued claim may not reflect a removal immediately. | Check both token handling and whether the server revalidates membership; a server does not automatically invalidate a still-valid token. |
| What if a function changes effective privileges? | Review exposed functions, especially SECURITY DEFINER functions, for tenant scoping and execution privileges. | Review database functions too; moving request handling to a server does not make an unsafe function harmless. |
| How are changes validated? | Test hostile-client requests against the deployed grants, policies, functions, and schema changes. | Test both server authorization and the database permissions it relies on. |
Failure cases that need extra scrutiny
Membership removal and existing tokens
DevOps Daily Team reports that in its tested setup, a removed member’s previously issued token continued working for its remaining lifetime. The article reports an observation of 900 seconds plus approximately 28 seconds; that figure is specific to the team’s configuration and is not an established Neon-wide revocation guarantee. The team says checking live membership in the policy addressed the issue. For an actual deployment, verify current token semantics and decide whether policies must consult current membership rather than rely only on claims issued earlier.
Functions, constraints, and cross-table policy checks
RLS on a table does not automatically make every function safe. A SECURITY DEFINER function can execute with the privileges of its owner, changing the effective security boundary; inspect its access rules and ensure tenant filtering is deliberate. PostgreSQL also documents that referential-integrity checks—including unique or primary-key and foreign-key checks—bypass row security. Poorly designed constraints can consequently reveal information through errors or other observable behavior.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Policies that consult other rows or tables also require care: PostgreSQL documents possible race conditions in which concurrent updates allow a policy evaluation to use data from an earlier snapshot. These issues matter when tenant membership, ownership, or authorization depends on mutable related records.
When this architecture is a reasonable fit
A direct Data API can be a practical choice when the application’s operations map cleanly to database permissions, the team can maintain policies and grants as security-critical code, and hostile-client testing is part of schema changes. A custom server may be preferable when authorization depends on complex workflows or external checks that do not fit the database boundary cleanly. Neither choice removes the need to constrain the database role and verify the effective permissions for every exposed operation.
Quick Recap
- Map each client action to the required table, command, and columns before granting access.
- Enable RLS on every tenant-scoped table and verify the API role is subject to it.
- Review all permissive and restrictive policies together, including both existing-row and inserted-row checks.
- Inspect exposed functions independently, with particular attention to SECURITY DEFINER behavior and tenant filters.
- Test cross-tenant reads and writes, wrong-role actions, filters, joins, aggregates, bulk changes, and upserts using hostile-client requests.
- Retest after changes to roles, grants, policies, functions, schema, or membership and token behavior.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
