The code I was looking at was not causing the behavior

A client reported that users covered by access restrictions could still open protected files. Every permission category relying on the same restriction mechanism showed the defect.

I received the problem description and the assignment to reproduce the behavior, locate its cause and correct it.

A newer security implementation had been released earlier. Because it was recent and directly related to the affected behavior, it was the first reasonable hypothesis.

I reproduced the behavior on a test machine. The available logs did not contain enough information to identify the cause, so I traced the execution flow with a debugger.

1. LoadThe user entity entered memory with the correct restrictions.
2. Later callAn older module that remained active ran immediately afterward.
3. OverwriteThe module directly replaced the restrictions on the same user entity.
4. AuthorizeThe application used the modified in-memory entity as the authorization credential.
5. OutcomeUsers could open files that should have remained restricted.

The newer implementation produced the correct state. A later legacy step changed that state before authorization was enforced.

I removed the references and calls to the obsolete module. Validation confirmed that users covered by the restrictions could no longer open the protected files, while authorized users retained access.

The correction was included in a new release as a security patch.

The immediate cause was specific: the obsolete module overwrote the restrictions.

The codebase also contained public attributes, mixed responsibilities and direct calls between modules. Multiple components could alter shared state, and the relevant execution path was not visible in the available logs.

These conditions made the interaction harder to discover and predict. They do not prove why the defect was introduced.

I explored a limited proof of concept in a parallel development line. It tested clearer separation of responsibilities, stronger encapsulation and fewer direct state mutations across selected modules.

The exploration exposed additional dependencies. A transformation of that scale would have required broader team participation and was not adopted within the project's constraints.

In retrospect, a smaller scope, a narrower demonstration and evidence tied directly to the next decision might have made the proposal easier to evaluate. That is a hypothesis, not a proven explanation for the outcome.

The code that appears to explain a behavior is not always the code producing the final result. Follow the behavior, observe where state changes and revise the model when the evidence contradicts the first hypothesis.

This case study passed desktop, mobile, accessibility and confidentiality validation before publication.

Explore other evidence