07 · Testing · Privilege
The button is hidden. The API still spills another store's members
The security tester uses an over-privilege request to prove the server really refuses. Hiding a button is not a fix he will accept. How the privilege model is designed is a constraint from the security architect. He does not make the law.
Development: The export button is already hidden by privilege.
Security tester: I do not use the button. I take this store's session and request another store's members. Phone numbers still come back.
The security tester proves the constraint has no bypass
The security architect wrote that export is not allowed and that filter by store is required. The security tester hits those sentences with requests. What marks this role is that he does not start from the UI menu. He uses a low-privilege account, changes parameters, drops pagination, and replays someone else's document number. Not seeing an entrance on the page does not mean the API refused. He records the request, the response count, and whether it contains fields that should not be seen. If it contains them, it is a defect. Severity follows whether the data is phone numbers, amounts, or the whole database.
He also tests the session after login: whether a leaver's account dies at once, whether a shared implementation account is still alive, whether an uploaded file can become executable content. These have nothing to do with the business peak, but the go-live check must have them. He does not accept “please don't do that” as a fix. The fix must be a server refuse, and the refuse must be written into the audit.
Regression hits the same request
Development says it now filters by store. Security testing hits the original request again. He does not look at the code. If the filter was only written on one API, the export API may still be the old one. He keeps a set of over-privilege cases. Before they enter automation, he confirms by hand that they really stand for an attack. Automation only stops a step backwards. It does not replace him finding a new entrance.
The whole database after pagination is dropped
A store account was only supposed to see this store's members. In the request he enlarged pagination and swapped the store code for another store. Two hundred phone numbers came back. The button was indeed hidden. After the defect went back, the server forced the filter from the stores bound to the account, and export went through approval. Security testing replayed the original request with a script. The response became a refuse, and the audit showed that refuse. Pass evidence is the refuse record, not a sentence that says “fixed.”
A fix with no refuse record is a defect he will not close. The security tester also checks the export file itself. If a file after approval can still be downloaded by someone who was not approved, using the old link, the defect stays open. The link must expire. After it expires, access should refuse. He retries the download in the same minute privilege is retracted, to prove retracting was not only a change to the menu on the page. Menus lie. Links are harder to lie with. On the upload entrance he tries a script dressed as an image, an oversized member file, and a duplicate file name. Even if the system does not execute the script, it must not put the original file in an accessible directory as an attachment download. The reason given to the uploader should be written for them. The audit records the real reason separately. The more detail you give the uploader, the more you must confirm no internal path leaked. He tries, with an ordinary clerk account, to hit the supervisor-confirm URL directly.
The page may say no privilege, but the API must also refuse, and must not return document content. Many implementations only block submit, yet already gave the detail out. Cost, supplier, and phone number in the detail are already enough for a leak. A no-privilege response must not reuse the structure of a normal detail, and must not merely hide a button. He keeps this refuse's request ID on the regression list. The next time privilege changes, replay the same request first, then look at the code diff. Looking only at the code diff easily misses another entrance still using the old query. Security testing trusts replay. It does not trust an explanation.