A good-looking form does not store requests. Start with a mock if that is enough to validate the journey. Add a database or CRM only when you know why it is needed and who can read and change the records.
Answer these data questions first
- Which fields do you need to respond to the user? Do not collect extras “just in case”.
- Who can read a submitted request?
- Who can change or delete it?
- How long do you need the data, and how can it be removed?
- How can you test that one user cannot read another user’s record?
Use fictional records in this course. Do not upload customer correspondence or work passwords to a public builder.
If you choose Supabase
The browser can call the Data API only within the granted roles and policies. Supabase’s official Row Level Security guide describes two distinct layers: grants permit a role to operate on a table; RLS filters which rows that operation can access. Enabling RLS alone is not enough if broad grants are still present. Also review the Data API security guide.
Define rules separately for SELECT, INSERT, UPDATE, and DELETE. Test both allowed and denied actions. For a multi-user app, include a test that changes the record or tenant ID; a successful login alone does not prove isolation.
Secrets and integrations
A public project key may be intended for browser use. A privileged secret is not. Store server secrets in a server environment or secret store; let the backend verify the user and perform only the required action. Never leave a secret in HTML, client JavaScript, a screenshot, or a public Git repository.
Add a CRM through a small adapter with explicit inputs, outputs, timeouts, and errors. A CRM failure must not look like an accepted request.
| Role | Read a request | Create | Change |
|---|---|---|---|
| Signed-out visitor | No | Only the permitted public submission | No |
| Owner/operator | Yes, within their role | Yes | Under the agreed process |
| Another user | No | Their own request only | No |
This is a discussion example, not a universal access policy. Approve roles before using real personal data.
Practice
- Fill in the data and access worksheet.
- Choose a mock, database, or API and explain why it is enough for version 1.
- List an allow and a deny test for every operation.
- Check the browser bundle for secrets; do not create production keys for this exercise.
- Simulate an unavailable database or CRM and make the app show an honest failure with a manual fallback.
Save: field map, access matrix, allow/deny tests, and storage decision.
Self-check
- Can any role read another person’s request?
- Can client code call a privileged API directly?
- Can you explain what data is stored and why?