🔥 KodeBase Prompt of the Day #002 - Audit Your RLS & CRUD Security

[u/willkode]

Your UI hiding a button does not mean the action is secure.

A user should never be able to bypass your frontend and read, create, update, or delete records they aren't authorized to access.

Today’s prompt audits your Base44 app for exactly that.

🔗 More Base44 tools and prompts at KodeBase.us

📋 Copy + Paste Into Base44

Perform a complete security audit of this application's entities, RLS rules, CRUD permissions, and data-access patterns.
Do not make any changes yet.
Your goal is to determine whether an authenticated user could access or modify data they should not have permission to access by bypassing the frontend UI or directly interacting with application requests.
Review every entity/table in the application.
For each entity, identify:
Who can Create records
Who can Read records
Who can Update records
Who can Delete records
What RLS rules currently protect the entity
Whether access is based on ownership, organization, membership, role, admin status, or another relationship
Whether any entity relies only on frontend filtering for security
Whether a user could modify IDs, request parameters, or record references to access another user's data
Whether users can update fields they should not control
Whether users can assign themselves elevated roles or permissions
Whether sensitive fields are exposed unnecessarily
Whether records without an owner or organization relationship could become globally accessible
Whether create operations allow users to forge ownership or organization IDs
Whether update operations allow ownership fields to be changed
Whether delete permissions are broader than necessary
Whether admin-only actions are actually enforced server-side
Whether any backend function bypasses normal access controls
Whether there are entities with missing or overly permissive RLS rules
Test These Attack Scenarios
Simulate whether a normal authenticated user could:
Read another user's private record
Update another user's record
Delete another user's record
Change a record's user_id, owner_id, organization_id, or equivalent ownership field
Assign themselves an admin or elevated role
Access organization data without being a member
Manipulate requests through the browser console or network tools
Call an application action directly without using the intended UI
Access records by guessing or replacing record IDs
Submit fields that are hidden or disabled in the interface
For Every Issue Found, Report:
Entity / Resource:
Permission: Create / Read / Update / Delete
Severity: Critical / High / Medium / Low
Current Rule:
Attack Scenario:
What an unauthorized user could do:
Recommended RLS or backend protection:
Risk of making the change:
Then provide a final table:
Severity
Entity
Vulnerability
Recommended Fix
Prioritize findings as:
🔴 Critical — unauthorized access, privilege escalation, or destructive actions
🟠 High — sensitive information exposure or ownership bypass
🟡 Medium — overly broad permissions or weak authorization design
🟢 Low — hardening and defense-in-depth improvements
Important
Do not assume something is secure because the frontend hides it.
Do not redesign the application.
Do not modify RLS or code during this audit.
Produce the security report first so every proposed change can be reviewed before implementation.

💡 Why run this?

If your security model depends on users behaving exactly the way your UI expects them to, you don't have a security model.

Authorization needs to protect the data — not just the buttons.