Phoenix Security

Penetration testing, proven by hand.

Web applications, APIs, networks and mobile apps, tested by hand. Every finding comes with the request, the response and the fix.

Request a scope See the five services

1 Services

Five kinds of test. Each one lists what it covers and what we need from you, so you can compare them side by side.

ServiceWhat we testYou provide
1.1Web applicationDetails Access control between users and roles, injections, business logic, sessions, file upload and configuration. First with no account, then with one account per role. The URLs in scope and a test account for each role.
1.2APIDetails Object and function level authorization, tokens and authentication, mass assignment, rate limits and input handling, across REST and GraphQL. An OpenAPI file or Postman collection, and keys for each role.
1.3External networkDetails Everything you expose to the internet: hosts, open services, VPN and remote access, mail, forgotten admin panels and files left online. Your IP ranges and domains, and written consent from any host.
1.4Internal networkDetails What an attacker reaches from one foothold inside: Active Directory, privilege escalation, lateral movement and segmentation between zones. A VPN access or a machine on the network, and a standard user account.
1.5Mobile applicationDetails iOS and Android apps and the API behind them: local storage, certificate pinning, login flows, secrets in the build, deep links. The build (IPA or APK) or store link, and test accounts.

2 Method

Tools find the surface. They never make a conclusion. Every step below is done by hand, in this order.

  1. 2.1

    Scope and sign

    We agree the targets, the test windows and who to call. You sign the authorization. No request reaches your systems before that.

  2. 2.2

    Test with no access

    A first pass with no account and no inside information, the way an outside attacker starts.

  3. 2.3

    Test with accounts

    A second pass with one account per role. Each role tries to reach what belongs to another.

  4. 2.4

    Prove it

    Each finding is exploited or shown, with the request, the response and a screenshot. What we cannot reproduce is reported as an observation, not a vulnerability.

  5. 2.5

    Report

    You get the full report at the end of the test.

  6. 2.6

    Retest

    Once you fix, a retest checks each finding and gives you an attestation.

3 Evidence

This is what a finding looks like in our reports. The proof sits next to the claim, so your developers can replay it and your managers can read what it means.

Phoenix Security

Penetration test report

Example finding

Any signed-in user can read any customer’s invoices

Severity: High

An ordinary customer changes an invoice ID and reads another customer’s invoice.

Read the full findingHide the full finding
Weakness
CWE-639
CVSS 4.0
AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Found in
Test with accounts (2.3)
Status
Proven

Proof

  1. 1We are signed in as user 1042, an ordinary customer.
  2. 2We ask for invoice 88213 by changing one number in the URL.
  3. 3The server returns it. It belongs to customer 2291, with their name and bank details.
Figure 1. Request
GET /api/v2/invoices/88213 HTTP/2Host: app.example-saas.comCookie: session=7f3a…c91eAccept: application/json
Figure 2. Response
HTTP/2 200 OKContent-Type: application/json {  "invoice_id": 88213,  "customer_id": 2291,  "customer_name": "             ",  "iban": "FR76                0189",  "amount_due": 18400.00}

Remediation

  1. Enforce object-level authorization on the server. Load the invoice, then compare its account ID with the account in the caller’s session before returning any data.
  2. Return 404 Not Found when the check fails, so the response does not confirm that the invoice exists.
  3. Put the check in one shared layer (middleware or data access) and apply it to every endpoint that takes an object ID, not route by route.
  4. Add a regression test that requests another account’s invoice and expects 404.
  5. Search access logs for invoice requests outside the caller’s account to find out whether the flaw was used before the fix.

Random IDs such as UUIDs make the flaw harder to find. They do not fix it.

Retest

Request invoice 88213 as user 1042. Expected result: 404, no invoice data.

References

OWASP Top 10:2025, A01 Broken Access Control. OWASP ASVS 5.0, requirement 8.2.2.

Written for this page. Not taken from a client report. Personal data is masked in real reports too.

4 Deliverables

You get documents your developers can act on and your management can sign off.

DocumentWhat it holdsFor
Technical reportEach finding with its exploit path, proof, CVSS 4.0 score, CWE and fix.Developers, IT
Executive reportFive to eight pages on business risk, in plain words.Management, board
Remediation planFindings ranked by what to fix first.IT, project leads
ReadoutA remote session to walk through the findings and answer questions.Both
Retest attestationProof that the findings were fixed.Auditors, clients

  • Technical report

    What it holds
    Each finding with its exploit path, proof, CVSS 4.0 score, CWE and fix.
    For
    Developers, IT

  • Executive report

    What it holds
    Five to eight pages on business risk, in plain words.
    For
    Management, board

  • Remediation plan

    What it holds
    Findings ranked by what to fix first.
    For
    IT, project leads

  • Readout

    What it holds
    A remote session to walk through the findings and answer questions.
    For
    Both

  • Retest attestation

    What it holds
    Proof that the findings were fixed.
    For
    Auditors, clients

For regulated firms: reports can be split per entity, so each one can answer its own regulator. Reports are written in English or French.

5 Rules of engagement

These hold on every test, whoever the client.

  1. 5.1

    No test starts before the authorization is signed. Scope is what the document names, nothing more.

  2. 5.2

    Tests run from fixed IP addresses given in advance, inside agreed time windows, so your team can tell us from a real attack.

  3. 5.3

    No denial of service. No data is changed or deleted. No real customer data is extracted. Proof is kept to the minimum and masked.

  4. 5.4

    Testing stops, and your contact is called, if we reach personal data in clear, take over a production system, or see any effect on availability.

6 Company

Phoenix Security is a penetration testing firm. The testers who scope your test are the ones who run it and sign the report.

Research

Several critical vulnerabilities in a desktop tax preparation product used by millions of people in the United States. Reported to the vendor. The vendor is fixing them.

Name withheld until the fix ships, under coordinated disclosure.

Certifications

CertificationScopeIssuer
OSEPEvasion and intrusion in defended networksOffSec
OSCPHands-on penetration testing, timed examOffSec
CRTORed team operationsZero-Point Security
PenTest+Method, scoping, reportingCompTIA

7 Request a scope

Tell us what needs testing. The reply comes from a tester, not a sales team.

What should we test?

Number of apps or IP ranges, user roles, deadline, and why now (a client, an audit, a regulator).