Supabase application practice

Start with an access matrix. List the actors, resources, and permitted actions. Separate an organization's administrator from a platform administrator and an ordinary member. Decide what happens before an invitation is accepted and after access is revoked. Ambiguous roles create ambiguous policies, regardless of the database technology.

Create synthetic users in at least two organizations. Add records that would reveal a leak if the wrong user could read them. Test reading, creating, editing, and deleting independently; a correct read policy does not prove that writes are safe. Include attempts to change the organization identifier on an existing record.

Supabase's row-level security documentation explains how policies can constrain access at the row level. It also warns about privileged service-role access, which can bypass row-level security and must not be exposed to clients. For this exercise, distinguish tests run as an ordinary user from tests run with privileged credentials. Passing only privileged tests tells you little about a user's actual authorization behavior.

Add a revocation scenario. A user who had access yesterday should not retain it indefinitely because the interface still displays an old state. Explain which information is cached, what the server checks, and what happens on the next request. Do not claim a simple demonstration establishes protection against every possible attack; document the boundary you tested.

Investigate one slow query only after the access model is clear. Use a defined synthetic workload, compare alternatives, and report the conditions of the measurement. A faster query that bypasses the intended permissions is not an acceptable optimization. Likewise, adding indexes without explaining their effect and maintenance cost is incomplete reasoning.

Write a short incident scenario: a test discovers that a member of one organization can read another organization's record. What would you stop, inspect, fix, and retest? In a real environment, escalation and evidence handling would follow the organization's procedures. In your portfolio, demonstrate the reasoning using invented data rather than conducting unauthorized tests on live systems.

For engineering, provide the model, policies, tests, and a brief performance analysis. For support or solutions, write the diagnostic plan and customer explanation. For product or design, show how administrators understand roles and recover from configuration mistakes. For commercial roles, explain why the governance requirements matter to a customer's adoption decision.

Evaluate correctness across the access matrix, quality of failure messages, reproducibility, and clarity of the remaining limitations. Do not grade the project by the number of database features used. A small application with a defensible security boundary is more useful than a broad demo whose access rules are accidental.

Second-stage test: test access changes, not only initial authorization

Extend the multi-tenant case with a user who changes organizations or loses membership. Test both an existing session and a newly established session, and identify assumptions about when permission changes become effective.

Add a background operation with broader privileges than an ordinary user. Explain why a successful privileged test does not establish that the user-facing authorization boundary is correct.

Publish a small authorization matrix and negative tests for prohibited actions in your own sandbox. Do not use another organization's application or live customer data. State the cases your implementation has not covered.