---
title: "Discussion on \"Testing the Permission Matrix\" | Hashnode"
description: "Discussion on \"Testing the Permission Matrix\". A matrix that only proves the admin can do everything has not really been tested."
url: "https://hashnode.com/posts/testing-the-permission-matrix/6af6848915b3f54fcb175343"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Testing the Permission Matrix](https://blogs.powerduck.com/testing-the-permission-matrix?utm_source=hashnode&utm_medium=feed)

A matrix that only proves the admin can do everything has not really been tested.

18h ago · 5 min read · blogs.powerduck.com  
Read the article

-   [#api](https://hashnode.com/tag/api)
-   [#testing](https://hashnode.com/tag/testing)
-   [#debugging](https://hashnode.com/tag/debugging)
-   [#security](https://hashnode.com/tag/security)

## Written by

[Powerduck](https://hashnode.com/@powerduck)

@powerduck · hon

  
[View profile](https://hashnode.com/@powerduck)

## Responses 2

Markdown supported · ⌘↵ to post

[Daniel Collins](https://hashnode.com/@fabbalancecheckuae)

[15h ago](https://hashnode.com/posts/testing-the-permission-matrix/6af6848915b3f54fcb175343/comment/6af6b0852b691df1c0fc08ac)

The point about asserting beyond the status code is the one I would underline. A 403 that still leaks a field in the body, or a denied write that quietly went through, is worse than a plain failure because it looks correct in a test report.

One case I would add to the matrix is ownership changing over time. A user who was an owner yesterday may be a collaborator today, and a token issued before that change can behave differently depending on how permissions are checked. Testing the matrix only with freshly issued tokens can miss that.

I also think the matrix works best when it is treated as a living document, not a one-off test artefact. Every time a new role or resource is added, the new row should force a review of the default-deny rule, otherwise the coverage quietly drifts out of date.

[OneLifeVibe](https://hashnode.com/@onelifevibe)

[17h ago](https://hashnode.com/posts/testing-the-permission-matrix/6af6848915b3f54fcb175343/comment/6af68ea9590228d22a226996)

The framing of the matrix as the oracle really clicked for me. Testing only the admin path and one obvious deny leaves exactly the combinations where a lower role reaches a higher privilege action or one user reaches another user's object, which are the failures that matter most. I also appreciated the point that a correct 403 is not enough on its own, since a denied write can still have a side effect and a response body can still leak protected fields. Treating default deny as something that needs its own explicit test, rather than an assumption, is a discipline I want to adopt.