Business Logic Penetration Testing Case Study: Approved Purchase Orders Could Still Be Modified

This grey box web application penetration test of a B2B procurement platform checked whether a manager’s approval stayed tied to the exact purchase order the manager had reviewed. It didn’t: a backend function still accepted changes to approved orders, so an ordinary employee could increase an order’s value without invalidating the existing approval.

Engagement	Details
Scope	Web application, REST API, approval workflows, and ERP integration
Approach	Grey box
Effort	7 tester-days, plus 1 tester-day for retesting
Retest	Direct editing, imports, attachment changes, resubmission for approval, and a regression check of the normal purchasing workflow

Key takeaways

• The obvious authorization checks worked: an employee could not approve their own order or access the manager’s approval interface.
• After a legitimate approval, a backend function used to save draft orders still accepted changes, and the ERP integration retrieved the changed order.
• The first fix blocked the main order-editing endpoint, but retesting found the same outcome through the line-item import function, so the finding was marked partially remediated.
• The final fix introduced shared version checks across all modification paths, and the ERP integration accepted only the version that had completed approval.

What did the client need tested?

A B2B procurement platform was preparing for deployment across additional business units. Employees could submit purchase requests, managers approved expenditure, and the procurement team transferred approved orders to an ERP system for fulfillment.

The platform relied on a multi-stage approval process. Orders above a defined threshold required an additional approval, and employees could not approve their own requests.

The assessment focused on a question that role-based access checks alone could not answer: did an approval remain tied to the exact order details the manager had reviewed?

Testing took place in a pre-production environment with four user roles and a test ERP integration. Actual purchases and communications with external suppliers were excluded.

What did the business logic penetration test find?

The obvious authorization checks worked correctly. An employee could not approve their own order or access the manager’s approval interface.

The weakness appeared after an otherwise legitimate approval.

A tester created a low-value order and approved it using an authorized test account. Although the interface then disabled editing, a backend function used to save draft orders still accepted changes to the approved record.

Increasing the quantity of a product changed the total order value without invalidating the existing approval. The integration process checked whether the order was marked as approved, then retrieved its current contents, including the changes made after approval.

Approval was attached to the order identifier, not to an immutable version of the order.

The manager-facing history also failed to make the post-approval change sufficiently visible. Exploitation did not require an administrator account; an ordinary employee role was enough to demonstrate the issue.

Why didn’t functional tests and automated checks catch it?

Functional tests covered the intended approval sequence and verified that employees could not approve their own purchases. They did not test changes between approval and fulfillment.

The automated security checks used in this scenario evaluated individual requests without a model of the business rule: changing material order details must invalidate previous approvals.

Each request was technically valid. The vulnerability was in the relationship between them.

For more on where automated checks stop and manual testing starts, see penetration testing vs vulnerability scanning.

How was the approval flaw fixed and retested?

The first fix blocked modifications through the main order-editing endpoint. During retesting, however, the same outcome remained possible through the line-item import function. The finding was therefore marked as partially remediated.

The final implementation introduced shared version checks across all modification paths. Changes to the supplier, order value, or line items invalidated existing approvals. The ERP integration accepted only the specific version that had completed the approval process.

The complete fix was delivered within eight business days. Retesting covered direct editing, imports, attachment changes, and resubmission for approval. The normal purchasing workflow was also checked for regressions.

Each finding’s retest status is recorded in the report, as in section 7 of our sample penetration test report.

Key takeaway

Correct permissions on individual functions do not guarantee a secure business process. An approval must remain bound to the information that was actually reviewed.

Need the same test for your B2B application?

This engagement was a grey box test of a web application, its REST API, approval workflows, and ERP integration: 7 tester-days, plus 1 tester-day for retesting. The scope covered the REST API alongside the web interface; see API penetration testing for how that layer is tested. Logic flaws that automated scans missed also drove our fintech API penetration testing case study.

A standard web application or API test at Pentestica falls in the $2,500–$5,500 range; see how tester-days translate into a fixed price, or request a pentest quote with your user roles and the workflows that matter most.