---
title: "Comment by Daniel Collins on \"Testing the Permission Matrix\" | Hashnode"
description: "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 t"
url: "https://hashnode.com/posts/testing-the-permission-matrix/6af6848915b3f54fcb175343/comment/6af6b0852b691df1c0fc08ac"
---

[Discussion](https://hashnode.com/posts/testing-the-permission-matrix/6af6848915b3f54fcb175343)

Comment [Testing the Permission Matrix](https://hashnode.com/posts/testing-the-permission-matrix/6af6848915b3f54fcb175343)

[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.