Why can the intern see my salary?

That’s a question you want answered before the first employee asks it.

Picture a routine demonstration of a new internal app. The manager is pleased. The employee directory looks clean, the search works, and somebody clicks Export. Names and departments appear in the spreadsheet. So do salaries.

The junior employee hasn’t broken into anything. They used a button you gave them. Now the discussion has moved from whether the software is finished to who else has downloaded the file.

This is an illustrative scenario, like the meeting-room scene on the cover. It is not a report of a client breach. It is a useful way to expose a weak acceptance criterion: “The admin screen is hidden, so ordinary users can’t see the data.”

A missing button proves very little

Signing in establishes who someone is. Authorization determines what that person may do. Those are separate jobs. OWASP’s authorization guidance recommends minimum necessary access, denying access unless it is allowed, and validating permissions on every request. The decision must be enforced by trusted application components, not just by what the browser displays.

In our example, removing the salary column from the directory might improve the screen while leaving the underlying response unchanged. The same data could still be delivered to the browser. A separate export function might also return a broader set of fields.

OWASP describes unauthorized access to individual fields as broken object property level authorization. Permission to view an employee record does not automatically include permission to read or change every field on it. A service should return only the fields the caller is permitted to receive and accept only the changes they are permitted to make.

For a buyer, the consequence is straightforward: a polished demonstration can miss the exact boundary you are paying the software to enforce.

Agree on the rule before asking whether it works

“Staff access” is too vague to approve. Start with a specific job. In a hypothetical business, a new coordinator needs colleagues’ names, work contact details and availability. A department manager needs information about their own team. Payroll staff need compensation records. Someone must also decide who can change those records and who can download them in bulk.

Write the decisions in ordinary language. For example: “Coordinators can export the work directory, but compensation fields must not appear in that export.” Or: “Managers can approve changes for their assigned department; they cannot approve their own change.” These are proposed business rules, not a universal payroll policy. Your organization has to choose the right ones.

Salary transparency can be an intentional company policy. The problem here is accidental disclosure through software, not employees choosing to discuss their pay. Decide what the application should disclose deliberately, including which other personal fields remain restricted.

For each workflow, name the people, records, fields and actions involved. Treat viewing, editing, exporting and sharing as separate decisions. A team member might legitimately need to read a record without needing the ability to distribute a whole dataset.

Ask for a demonstration with the ordinary account

An administrator clicking through every screen tells you what an administrator can do. It does not show the limits of an intern, contractor or manager. OWASP’s authorization testing guide includes checks across different roles and between different users with equivalent privileges.

Ask your development team to demonstrate those boundaries in an approved test environment using fictional records. Give them a few concrete tasks:

• Export the directory as the coordinator. Inspect the file, including columns outside the initial spreadsheet view.
• Open a fictional employee record as that employee’s manager, then as a manager from another department.
• Try an agreed restricted action through the underlying application request, not only through the menu. The team should show that the server refuses it.
• Remove a test user’s payroll access and demonstrate how quickly their existing session loses that ability.
• Generate a test report, then check who can open its download link and what happens after the link expires or access is withdrawn.

The expected result needs to be written down before each test. Otherwise, “that’s how it’s supposed to work” becomes a convenient explanation for whatever happens. Keep the permitted path working too: a fix that stops payroll staff doing payroll has created a different problem.

This is a focused acceptance exercise, not a complete security assessment. The relevant cases depend on the application, and the people testing it need authorization to do so. The useful evidence is the agreed rule, the account used, the action attempted and the actual result.

The download is part of your product

Once the spreadsheet leaves the application, changing a permission cannot pull back someone’s existing copy. That is a practical reason to examine exports early, including scheduled reports and attachments sent by integrations. Ask where each copy goes and who controls it.

OWASP also recommends protecting static resources and reviewing permissions as the system evolves. Apply that to the reports and documents your application creates. A restricted screen and an unrestricted file link are two different outcomes.

Give someone responsibility for access changes when people join, move teams or leave. Keep a record of what was granted and why. When a supplier adds a new reporting feature, revisit the affected rules instead of assuming the original sign-off covers it.

“We trust our staff” does not finish the job

Trustworthy people still click the wrong link, forward a file or use a feature exactly as it was presented. In the opening example, blaming the junior employee would avoid the more uncomfortable question: why did the system hand them that data?

If your supplier can show you the dashboard but cannot demonstrate the restrictions, the handover is missing something important. You do not need to become a security engineer to ask for that evidence.

At Rosecraft, we can review how roles and data access work in an existing application, identify gaps, and implement the agreed changes with tests that preserve the useful workflows. That can be a focused improvement to software you already own, rather than a replacement project.

Unsure who can see what in your application? Bring us the roles, the workflows and one example of information that should stay restricted. If you’re ready to hear what needs fixing rather than be reassured by a tidy dashboard, send Rosecraft a message. Let’s answer the question before an employee has to ask it.