API security for a store and an account area: a quiet risk
The storefront can look fine while the API returns someone else's order for a swapped number.
A modern store is not a set of HTML pages. The app, widgets, delivery and payment all talk to an API. That is where a bug hides that the storefront does not show: the user is signed in, but the object is not theirs. Changing an id in the request opens someone else's data. The page still draws as usual.
What to check besides "the site opens"
- Someone else's order, address or file by swapping an id. That is the first probe.
- Methods that should belong only to staff, but answer a customer token.
- Limits on login and on sensitive actions. Without them, guessing is cheap.
- Validation of the request body. Extra fields the API quietly accepts later show up in discount or status logic.
A scanner of the homepage usually misses this. You need a check of permissions and paths, meaning a pentest of the application and the API, not a screenshot of the storefront. Limits, splitting public methods from internal ones and watching anomalies are hygiene, even for a small store.
If we build the account area or the store, API checks sit in development and in the pre-release pentest, not "someday after". An existing plane can also be reviewed inside an agreed scope.
Related Lexora services
Does the store or account area have an API?
We will check permissions and common logic holes before an incident.