Web Application & API Penetration Testing

A customer changes one number in a request. Your application hands over someone else's invoice.

Every test is run by hand by a senior tester working through your access control and business logic, which is exactly where that invoice slips out and a scanner sees nothing wrong. Final Frontier Security tests web applications and APIs of every shape, from customer portals and SaaS platforms to REST and GraphQL APIs, webhooks, and mobile backends.

In this example, the customer used their own account, through the same API your application uses every day. They didn't need a stolen password. A feature built to serve a customer gave them access to data entrusted to you by someone else.

The invoice may show what that customer buys, how much they pay, and where the goods are delivered. A competitor could use those details to understand their purchasing patterns and shape an offer to undercut them.

Following the request

The application knew who they were.

Recognizing a customer and deciding which records they can reach are separate jobs. In the invoice example, the first job worked. The second failed. That failure is called an

To test it, we make the same request as different users. The invoice should open for its owner and remain out of reach for another customer. We also try privileged accounts. An administrator's authority should still end at their own customer's boundary.

Two customers share an application. They should not share access.

Customer A's administrator can read A's invoice. Changing the requested invoice to 1043 must not give that account access to Customer B's data. If it does, the customer boundary has failed.

Once that request is fixed, it is tempting to call the problem solved. But the invoice may be available through more than one feature.

See the account setup

Accounts that reflect your app

A scope that promises 'authenticated testing' tells you someone will log in. It doesn't tell you which differences in access they will test. The accounts should reflect who uses your application and what each person should be allowed to do.

For the invoice example

Customer A

Ordinary user
Administrator

Customer B

Ordinary user
Administrator

These four accounts let us compare ordinary users with administrators and one customer with another. In your application, the important differences might be between departments, employees and managers, or people who request and approve something.

The account setup determines which boundaries a tester can investigate. A compliance-driven penetration test probably won't tell you whether those boundaries were tested.

Beyond one endpoint

The invoice can have more than one way out.

An application might offer the same invoice on its own page, in a bulk download, and through a mobile app. Fixing the request that exposed it doesn't tell you whether that same customer can still retrieve it through the other two methods.

An export often passes through several parts of an application. One accepts the request, another gathers the invoices, and another serves the finished file. Even if only the right customer can download that file, it could still contain someone else's invoices.

We follow the data through those handoffs, testing whose invoices end up in the file and who can retrieve it, because both matter.

The right recipient. The wrong contents.

Here, Customer A requests an export of their invoices, but the application includes Customer B's invoices too. Only Customer A can download the file. That restriction works, but it doesn't protect Customer B's data inside it.

Following the code

One mistake can turn up in several features.

Source code can turn one finding into a search for the same mistake elsewhere. Once we find the invoice leak, we can examine the source code behind it and trace where that code is reused.

A developer may have copied the same approach into another feature, or several features may call the same piece of code. Seeing that connection gives us specific places to investigate during the assessment. We still test what each feature actually allows.

Providing source code helps us spend more of the testing time investigating weaknesses and their causes. Your developers get a clearer picture of whether they need to repair one feature or a pattern used throughout the application.

One finding gives us a thread to follow.

A leak in the invoice page can lead us to shared code used by the export and mobile app. That gives us a reason to test those features. It doesn't establish that they are vulnerable too.

Following the capability

A feature can work as designed and still be misused.

When an invoice is paid, your application might send a notification to the customer's accounting provider over the internet. The customer supplies the provider's receiving address. That automatic message is called a

Now suppose the customer replaces that address with one belonging to an administration service inside your private network. If your server accepts the address and can reach that service, the customer has made it send a request somewhere they couldn't contact directly. That misuse is called

A setting intended to connect the customer's accounting software has given them a way to direct requests into your private network. The feature may still send messages exactly as designed. The problem is what the customer can make it talk to.

Following the evidence

The attempts that failed belong in the story too.

Suppose the invoice API returns another customer's record, but the export refuses it. That blocked attempt matters. The two paths handled the same customer boundary differently. It gives engineering a useful comparison and shows where the application successfully protected the customer's data.

This is what the testing narrative in our report is for. It follows the investigation from the starting account through each meaningful result, including where a control held up and why we tried the next path. Your team can see how we reached the conclusion.

One retrieved invoice and access to an entire customer's history are different results. The narrative should make that distinction clear. Leadership needs to know what exposure was demonstrated. Engineering needs enough evidence to reproduce it and investigate the failed rule.

All of that detail should leave your team able to explain what went wrong in plain language.

That first customer never needed a stolen password. The application recognized them correctly. It simply gave them more than the business intended.

What a findings list leaves out

A list of vulnerabilities tells you what broke. A narrative also shows how the tester thought, which defenses stopped them, and why they changed direction. Open the report to see those differences marked in the margin.

Explore the annotated report

Illustrative report excerpt

Customer isolation in invoice retrieval

Illustrative scenario. The application, accounts, and results are fictional.

What the narrative adds

The result is only part of the story. These passages reveal the thinking and the unsuccessful attempts behind it.

The retrieval API crossed the customer boundary

We began with the supplied administrator account for Customer A and retrieved its invoice 1042. The account could manage A's invoices. We wanted to find out whether that authority would extend to another customer's records.Reading note 1 Keeping the same session, we requested Customer B's known invoice 1043. The API returned the full invoice, including item prices and the delivery address.

We confirmed invoice 1043's ownership using the supplied Customer B account. The Customer A administrator had no cross-customer role. This established that the API had disclosed another customer's record, rather than returning an invoice the account was entitled to read.

The export and ordinary-user checks narrowed the finding

Because the application also offered invoice exports, we tested that route next. A direct request for Customer B's invoice using the Customer A administrator session was refused, and no invoice content was returned.Reading note 2 An export of Customer A's own invoice succeeded. The export route enforced the boundary for this pair of requests even though the invoice retrieval API did not.

We wanted to learn whether the failure affected every user or depended on the administrator role.Reading note 3 We returned to the retrieval API using Customer A's ordinary-user account. It could retrieve invoice 1042 but was refused invoice 1043. The cross-customer disclosure was reproduced with the Customer A administrator account. The difference between roles gives engineering another comparison to investigate. Without source-code review, it does not establish which implementation decision caused the failure.

What this established

Testing stopped after the agreed cross-customer record was retrieved. We did not enumerate other invoices. The evidence confirms disclosure of one Customer B invoice to a Customer A administrator. It does not establish access to the customer's full history or a bypass of the export route.Reading note 4

The invoice retrieval API needs to enforce customer ownership for privileged accounts as well as ordinary users. The export and role comparisons give engineering specific behavior to examine. Other routes that return invoice data warrant review, but their exposure should not be assumed from this finding.

A findings list helps your team fix vulnerabilities. The narrative helps them understand how someone tried to break the application, what stopped them, and what they learned along the way.

Working with Final Frontier Security

What you can expect from FFS

How does FFS investigate beyond automated findings?

Senior practitioners learn your application's rules and investigate ways someone could misuse them. Tools, including AI, support that work. The testers pursue their own leads, verify what a weakness actually allows, and discuss findings with your team as they develop. Their involvement extends beyond reviewing a tool's results.

Can an FFS penetration test meet our compliance needs too?

Yes. We plan the assessment around your compliance requirements, including SOC 2 or PCI, and use the testing to help improve security too. That means investigating how someone could misuse your application and giving your team evidence they can use to fix the weaknesses we find. The report documents the tested scope and findings, with retest results following verification of fixes. An attestation letter is available on request. We agree on the scope and reporting requirements with you before testing so the engagement supports your audit as well as your security team.

What will our team learn from the report?

Your team can see what was tested, what exposure was demonstrated, and how the tester reached each conclusion. The report includes an executive summary, a testing narrative, a findings table, detailed write-ups, and the tested scope. The narrative also explains unsuccessful attacks and the reasoning behind the next test. A debrief call is available to walk through the results.

Can providing source code make the test more useful?

Yes. Source code helps us investigate why a flaw exists and find other places where the same pattern was used. That gives us more informed leads to test during the assessment and helps your developers understand the cause. We can also test without it. We agree on source-code access as part of the scope.

Is retesting included, and what does it cover?

Yes. After your team addresses the findings in our report, we retest those findings and document whether they have been resolved. Retesting is included at no additional charge. It covers the original findings, rather than a new penetration test of the application.

What accreditations and certifications does FFS hold?

Final Frontier Security is CREST accredited. Our team holds OSCP, OSWA, and OSEP from OffSec, and GWAPT from GIAC, SANS's certification organization. Other team credentials include CREST's CRT and CPSA, Zero-Point Security's Red Team Operator (CRTO), and The SecOps Group's CMPen-Android.

What can the assessment cover?

We test web applications, REST and GraphQL APIs, and APIs used by mobile apps. Scope can also include webhooks, the automatic messages applications send each other, and other integrations. We agree which interfaces, user roles, and business workflows are included before testing begins.

How long does a web application and API penetration test take?

Typically 3 to 4 weeks. The size of the application, the number of user roles, and the APIs in scope determine the testing effort.

What access does FFS need?

For applications shared by multiple customers, we aim for four accounts. An ordinary user and an administrator for each of two customers let us test both user permissions and separation between customers. We agree on the access needed for your application during scoping.

Start a conversation

Let's talk through your application.

Tell us what the application does, who uses it, and what prompted the assessment. Include any deadline your team is working toward.

We'll help you work out what the test needs to cover, why those areas matter, and what access and time the work will require.

Web Application and API Penetration Testing