A web application and API penetration test across an AI-powered B2B procurement platform, focused on the boundaries that matter most in multi-tenant software: who can authenticate, who can read whose records, and what an API will hand over when nobody checks.
B2B procurement software sits in the middle of a commercial relationship. It holds the contracts, the negotiated pricing, the supplier lists, and the approval chains that both sides of a transaction consider confidential. Buyers do not want their pricing visible to other buyers. Suppliers do not want their margins visible to competitors bidding on the same contract.
That separation is almost never physical. In a multi-tenant SaaS platform every customer's records live in shared infrastructure, and the boundary between them is enforced by application logic: a check in a controller, a scope on a token, a filter on a query. When one of those checks is missing, nothing crashes and no alert fires. The data simply comes back to whoever asked for it.
Adding AI to the workflow raises the stakes rather than changing them. Procurement data now moves through processing pipelines that summarize, classify, and route it, which means more services touching the same records and more places where an authorization decision has to be made correctly. The security question is not whether the perimeter holds. It is whether the application enforces the boundaries its own product page promises.
Across authentication, authorization, session handling, and input validation.
Fixes confirmed on retest before the engagement closed.
Acknowledged and formally accepted by the client.
The engagement covered the web application, its authentication flows, and every backend API behind it. Testing was conducted against all three user types the platform supports, buyer, supplier, and platform administrator, with each role tested against the others rather than in isolation. Most authorization failures only become visible when you hold one identity and reach for another identity's data.
Business logic flaws do not have signatures. An automated scanner can tell you that an endpoint responds, but it cannot tell you that a supplier should never have been able to read that particular contract, because it does not know what a contract is or who is supposed to see one. That distinction is why the API surface was enumerated and exercised by hand rather than crawled.
Findings were validated with reproduction steps and rated by real business impact before being handed over. The engagement closed with a retest cycle, which is where the remediation count comes from: 48 of the 50 findings were confirmed fixed rather than reported as fixed.
Six areas where the platform's trust boundaries did not hold up under attack.
Unauthorized access to procurement workflows and the supplier and buyer data behind them.
Authentication bypass means reaching a state the login flow was supposed to gate. It rarely looks like a cracked password. More often it is a flow that can be entered halfway, a token that is trusted without being verified, or a step that can be skipped because the server assumes the client followed the intended order.
Records, contracts, and supplier profiles belonging to one account reachable from another.
This class is what OWASP lists as the number one API risk, broken object level authorization. The request is properly authenticated, the session is real, and the server still returns a record belonging to somebody else because the only thing identifying the record was a value the caller supplied.
Movement between the buyer, supplier, and platform admin roles beyond what each role should hold.
Escalation runs in two directions. Horizontal movement gets you another account's data at your own permission level. Vertical movement gets you a higher level entirely, which on a procurement platform means reaching administrative functions from an ordinary supplier login.
Endpoints returning sensitive procurement and pricing data without an authorization check.
APIs frequently carry data the interface never displays. An endpoint built to populate one screen may return the full underlying object, including pricing and counterparty detail the front end simply does not render. The data is in the response either way.
Conditions allowing session hijacking and theft of authentication tokens.
Session weaknesses extend the window an attacker gets. Tokens that outlive their usefulness, sessions that survive a password change, or identifiers that can be captured and replayed all turn a single moment of exposure into ongoing access.
Room to manipulate data as it moved through AI-processed procurement workflows.
In an AI-assisted workflow, input validation stops being only about injection. Data that gets manipulated on the way into a processing pipeline influences what comes out of it, which means a validation gap upstream can quietly change a downstream result that a human then treats as authoritative.
An endpoint can be correctly locked to authenticated users and still hand every one of them the same records. The check that matters is not can this user call this route, it is does this user own this specific object.
Three roles do not produce three test cases. They produce every combination of who is acting and whose data is being touched, which is where privilege escalation paths hide.
Access controls enforced in the interface are decoration. Anything the browser can request, an attacker can request directly, without the JavaScript that was supposed to hide the button.
Two findings closed as accepted rather than fixed. That is a legitimate result when it is a documented, deliberate choice rather than a backlog item nobody got to.
AI SaaS platforms with multi-tenant data and role-based access.
B2B software handling procurement, financial, or sensitive operational data.
Platforms where cross-account data isolation is critical.
Five live phishing and crypto dusting scenarios run against the custody and operations teams. All five blocked.
Read the case study Fintech & Payments42 findings across a full AWS environment, from publicly readable buckets to a root account running without MFA.
Read the case studyBook a 30-minute walkthrough. We'll point CredShields at a scoped asset and show you live findings by the end of the call.
Get your comprehensive security audit from the team trusted by 200+ protocols and enterprises worldwide. Fast turnaround. Proven track record. Direct access to senior security engineers.