What it means
A vulnerability is a weakness that can enable harm. It may be a software defect, an unsafe configuration, an ineffective process, or a missing safeguard. Treat the weakness as something to understand and improve rather than blaming an individual who encounters it. A vulnerability can exist before an exploit is public or before any incident occurs.
Finding a weakness is the start of analysis. Confirm that it affects the relevant system and determine how it could be reached or used. Then consider consequences and existing controls. A technical severity label helps describe a flaw, but local risk also depends on exposure, business purpose, and evidence of exploitation.
The idea at a glance / Foundations
The weakness is the missing permission check.
A valid session and a well-formed identifier do not grant access to another supplier’s record. Compare the missing check with a corrected implementation and its bounded tests.
Fictional PlantPlan test variants V0 and V1, 25 September 2026. S17 owns P17; S29 owns P29. Policy allows suppliers to read only their own records. All records are synthetic.
READ THE PICTURE
Read the distinction and scope
V0 returns P29 to S17 because its owner check is missing. V1 refuses the same cross-supplier read and still returns S17’s P17. The tested weakness is authorization, while the session and identifier checks continue to work.
Keep in mindThese are controlled authored test cases, not a claim that a live PlantPlan release was attacked. Other operations, records, identities, and deployment paths remain outside this validation.
Read the complete example
- Read the distinction and scope. V0 returns P29 to S17 because its owner check is missing. V1 refuses the same cross-supplier read and still returns S17’s P17. The tested weakness is authorization, while the session and identifier checks continue to work. These fictional PlantPlan variants have an intended own-supplier read policy and a known service-managed association from a valid session to supplier S17. Synthetic P17 belongs to S17; synthetic P29 belongs to S29. Both V0 and V1 validate the session and accept the identifier syntax. In V0, the record handler lacks the object-level ownership/permission check before returning content. Controlled case V31 therefore returns a copy of P29 to S17 despite the intended policy. That missing service-side check is the vulnerability; changing the requested identifier from P17 to P29 is the method using it. In corrected V1, the handler obtains the authoritative P29 owner and checks the authenticated supplier before returning part content. Case V32 refuses S17’s P29 read because S17 is not S29. Independent positive case V33 returns S17’s P17, so the intended workflow still works. Originals remain at the service in every case. Format validation, authenticated transport, and a valid session do not substitute for object-level permission. The tests cover these chosen records, requester, operation, and implementations; they do not validate every route or establish any real attack history. V0 is an explicitly vulnerable teaching variant. V1 supplies the checked behavior used in the earlier trust-boundary example, so the two figures do not silently contradict the same service state.
These are controlled authored test cases, not a claim that a live PlantPlan release was attacked. Other operations, records, identities, and deployment paths remain outside this validation.
Diagram references: OWASP - object references and object-level access checks · MITRE CWE-639 - authorization bypass through a user-controlled key · OWASP - validate permission on every request
AN ILLUSTRATIVE SCENARIO
A small retailer file export
A retailer learns that an export feature allows a signed-in user to request another store's records by changing an identifier. The weakness is the missing server-side ownership check. The retailer validates the finding with synthetic records in an authorized test environment, identifies affected versions, and limits the exposed function while a fix is prepared. It also reviews available activity records without assuming that the existence of the weakness proves someone used it.
Put it to work
- Confirm the affected product, version, configuration, or process and preserve enough evidence to distinguish a real weakness from a scanner assumption.
- Document prerequisites, reachability, likely consequences, and operating safeguards; use that context to prioritize remediation or temporary mitigation.
- Assign an owner and retest the specific failure after the fix, checking that legitimate behavior still works and alternate paths are covered.
How to check your work
Show the original weakness with a safe authorized test, then demonstrate that the corrected system rejects the invalid case while allowing the intended workflow. Record the tested version and scope.
Connect the ideas
- Threat
A person, process, or event that might cause a loss to an asset.
- Exploit
A method or code that uses a vulnerability to cause an unauthorized effect.
- Exposure
Whether and how a vulnerability or service can actually be reached in this environment.
- Patch
A vendor or internal change that removes or reduces a vulnerability in running software.