Applications / APIs
Your application. An attacker's perspective.
Find the gaps between what your application allows and what your users should be able to do. Manual testing of authentication, access controls, and business logic across your web applications and APIs.
01 / Assessment coverage
Can one customer access another customer's data?
I test across user roles and tenant boundaries, following application workflows to establish what an attacker could actually access or change.
Authentication & sessions
Login, account recovery, multi-factor flows, session handling, and token lifecycle.
Authorization & tenant isolation
Object-level and function-level permissions, role boundaries, and separation between customer accounts.
API attack surface
Agreed REST or GraphQL endpoints, input handling, sensitive fields, and exposed functionality.
Business logic
Abuse of workflows such as invitations, approvals, payments, and account changes.
Input & server-side behavior
Injection, file handling, server-side requests, and other weaknesses relevant to the application's architecture.
Configuration & data exposure
Exposed secrets, error handling, deployment settings, and unintended disclosure of sensitive information.
Testing is informed by the OWASP Web Security Testing Guide, with coverage adapted to your architecture and business workflows.
OWASP Web Security Testing Guide02 / The engagement
Clear scope. Thorough testing. Useful answers.
You know what is being tested, how findings are communicated, and what happens next.
- 01
Agree the scope
Define your objectives, assets, access, testing windows, and rules of engagement. Scope and written authorization come first.
- 02
Test & validate
Combine manual testing with supporting tools. Investigate realistic attack paths and raise critical findings during the assessment.
- 03
Explain the risk
Receive a report with business impact, reproducible evidence, priorities, and practical remediation steps.
- 04
Support the fix
Walk through the findings together. Agree any remediation support and retest window in the proposal.
03 / What you receive
A report your team
can put to work.
Leadership needs the risk. Engineers need the evidence. Your report connects the two.
- Executive summary of risk and business impact
- Validated findings with evidence and reproduction steps
- Prioritized, actionable remediation guidance
- Coverage, limitations, and a findings walkthrough
04 / Before we start
A few good
questions.
Clear expectations make for a better engagement.
Can you test authenticated applications and private APIs?
Yes. We agree the roles, permissions, endpoints, and access method before testing. Accounts for different roles and tenants help test boundaries that an unauthenticated assessment would miss.
Do you need access to source code?
Source code is not required for a typical application penetration test. Documentation and test accounts help make the assessment more effective. If source review would add value, its coverage is agreed separately.
Should testing happen in production or staging?
A representative staging environment is often useful for testing workflows safely. If production is required, we agree test accounts, data handling, testing windows, and any restricted actions in advance.
How do you handle confidentiality and sensitive data?
Confidentiality, evidence handling, secure report delivery, and retention requirements are agreed before testing. An NDA can be arranged. Please use the initial enquiry to describe your environment without sending credentials or sensitive records.
Is retesting included?
Retesting scope, timing, and any associated fee are agreed in the proposal. When included, the retest checks the remediated findings and records their status; it is not a fresh assessment of newly added functionality.
Let’s talk about your security
Start with a conversation.
Choose a time to discuss web & api testing, your priorities, and the scope of an assessment.
Choose from my available times through Calendly.