SaaS Role Permission Testing: Share a Matrix Before Asking Peers to Try Your Demo

For SaaS role permission testing, define the expected action for each account and resource before inviting feedback on a public demo. Rehearse the task with separate test accounts, check the stored result and publish only the narrow behavior you actually verified. A viewer failing to find an edit button is useful interface feedback, but it does not establish that unauthorized edits are blocked.

Building in public can help you find people willing to question an access rule or try a confusing workflow. Give them a test they can interpret. “Try the app and tell me if permissions work” leaves both the permitted task and the expected result undefined.

The following workflow uses a fictional document-review SaaS. It is a proposed test plan, not a report of testing Buildside or another live product. Perform checks only in systems and disposable workspaces you own or are explicitly authorized to test.

Write the role and resource matrix first

Start with the smallest useful set of actions. The fictional app has documents inside workspaces. An editor can read and change documents in their workspace. A viewer can read those documents but cannot change them. Neither role can read another workspace's private documents.

Write each rule with a resource context. “Editor can edit” is incomplete. It leaves open whether the rule applies to every document, only assigned documents or everything in one workspace. A role label alone does not express the whole relationship.

For the example, the initial matrix contains four cases: viewer reads a document in their workspace; viewer attempts to change that document; editor changes that document; editor requests a private document in a separate test workspace. The first and third should succeed. The second and fourth should be denied.

Keep the expected result explicit. For a denied edit, the stored document must remain unchanged. For a denied read, the response must not contain the protected document. An error banner alone is insufficient evidence of either result.

The OWASP authorization testing automation guide describes expressing roles, services and test inputs in an authorization matrix. You do not need to adopt its sample implementation to use the underlying discipline: describe the allowed combinations before evaluating behavior.

Separate account identity from authorization

Prepare an editor account and a viewer account with different test identities. Keep their sessions separate so you can tell which one performed the action. A convenient administrator session should not stand in for either participant.

The OWASP authorization guidance distinguishes authentication from authorization. Signing in establishes identity; it does not mean every action is permitted. Its recommendations include checking permissions on every request and denying access by default.

For your rehearsal, record the account's role, workspace membership and document relationship. Also record the product version and relevant configuration. If you change a membership halfway through, that is a new condition, not a continuation of an identical test.

Use synthetic documents with obvious markers. For example, the original body can contain a fictional task description, and an attempted edit can add a distinctive test phrase. This makes it easier to check whether a denied operation changed anything without involving real customer material.

Run the permitted task before the denied task

Begin by confirming that the viewer can perform the intended read task. Can they open the document, understand that they are viewing it and find what they are allowed to do next? A secure but unusable screen still needs product work.

Then inspect the attempted edit condition. The interface may omit the edit control, show a disabled control or explain that another role is required. Ask a peer to describe what they believe their account can do. Their interpretation tests the communication of the rule.

Separately, use your authorized development test setup to verify enforcement at the request boundary. A hidden button is not that boundary. Check the response and the resulting stored document for the same action under the viewer's actual identity.

Run the corresponding editor case against the same synthetic document. If neither account can save because the test environment is broken, the viewer's failure tells you little about the permission rule. You need the successful comparison to interpret the denied condition.

Check the resource boundary as well as the button

Now use the second disposable workspace. Give it a private synthetic document whose marker differs from the first. Test that the editor from the first workspace cannot read it under the stated rule.

Keep this within your own authorized test environment. Do not invite public testers to enumerate accounts, guess other people's document identifiers or investigate production access. A useful community exercise can be narrow without exposing unrelated people to risk.

If you discover that an unauthorized action succeeds, stop the public demonstration of that path. Fix the issue and verify the boundary before sharing a reproduction that would enable misuse. Your public progress note can explain that a permission assumption needs repair without exposing operational details.

Also look for partial disclosure. A blocked document page might still display a private title, preview or attachment in another part of the interface. Your expected outcome should specify which information is allowed to appear, rather than treating one denied request as a verdict on the whole product.

Give founder peers an interpretable request

Once your own checks pass, prepare a small public review packet: the fictional task, the role being demonstrated, the expected result and the specific question you want answered. Include a screenshot or recording only if it contains safe test data.

A request could say: “This is the viewer flow in a fictional document workspace. The account can read, but cannot edit. Where does the page leave you uncertain about what to do next?” That invites interface feedback without asking volunteers to certify your security.

If you want a second developer to review the matrix, ask which relevant combinations are missing. They may point out attachment access, a changed membership or a document that moved between workspaces. Those suggestions improve the plan; they do not prove the missing cases pass.

Buildside is a founder community for public work. Wherever you ask, explain which part of the test is available to peers and which enforcement checks remain your responsibility. Do not describe a general comment as a completed independent audit.

Save evidence that survives the demo

Keep a short record for each case: initial document marker, acting account and relationship, requested action, observed response and final stored state. Mark a case untested if you did not run it. A tidy matrix full of assumed passes is less useful than a small matrix with honest gaps.

For interface feedback, save the participant's interpretation separately from the enforcement result. “The viewer thought they could request access” and “the viewer's update was denied with no stored change” answer different questions. Both can inform the next release.

If a condition changes, repeat the affected cases. A new attachment route or membership rule may introduce a path your earlier check did not cover. Avoid claiming that an old recording verifies a later version.

You can turn confirmed cases into regression tests through your project's established process. The article's manual rehearsal is a way to clarify expected behavior, not a substitute for a maintained authorization test suite or an appropriate security review.

Publish the boundary and the remaining question

An accurate build-in-public update names the checked scope. For the fictional app, that might be the viewer read/edit distinction and the separate-workspace read boundary in one test version. It should also name important cases that remain outside the check.

Show what the feedback changed: perhaps the page now explains why editing is unavailable, or the matrix now includes attachment access. Keep the distinction between a clearer interface and stronger enforcement visible in the follow-up.

Before inviting people into your next demo, ask whether a reviewer can identify the acting role, the resource, the expected result and the evidence of the final state. If those are clear, the conversation can move beyond “seems to work” toward a useful product decision.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

• OWASP: Authorization Testing Automation
• OWASP: Authorization Cheat Sheet
• Buildside founder community