Service
View Review ScopeAPI Security Testing
Authorization, object ownership, REST API security, GraphQL security, token scopes, data exposure, rate limits, and integration abuse cases.
Services
Security Services for SaaS and API Teams
A focused consulting model for SaaS security, API security testing, application security testing, asset visibility, vulnerability assessment, and security reviews that help product teams identify real attack paths.
Not sure which review fits? Start with a general request and I will recommend the right scope.
SaaS SecurityAPI Security TestingApplication Security TestingSecurity Reviews
Overview
Focused Review Capabilities
Each service is structured around practical testing, senior review, and remediation context for engineering teams.
API SECURITY
API Security Testing
REST and GraphQL API security testing for authorization flaws, object-level access issues, token scope problems, and hidden data exposure.
Explore API →PENETRATION TESTINGPenetration Testing
Manual web application penetration testing for authentication, sessions, access control, business logic vulnerabilities, and critical product flows.
Explore Pentest →ASSET VISIBILITYAsset Monitoring
External asset visibility for exposed endpoints, forgotten subdomains, hidden services, and internet-facing attack surface risks.
Explore Assets →VULNERABILITY ASSESSMENTVulnerability Assessment
Practical vulnerability assessment focused on real exploitable vulnerabilities, prioritization, and remediation guidance.
Explore Assessment →SECURITY REVIEWSSecurity Reviews
Focused reviews for launches, releases, high-risk SaaS workflows, APIs, and sensitive product changes.
View Reviews →CODE REVIEWSource Code Review
External code is not the only place flaws live. A manual read of the authorization logic, ownership checks and business rules in your own codebase.
Explore Code Review →Coverage
What Testing Actually Covers
All testing is manual. I use the application as each of its roles would, then try to do what those roles should not be able to do. These are the classes of issue I test for.
Broken access control
Data or actions reachable by a role that should not have them, including admin functions.
IDOR and BOLA
Changing an identifier in a request and getting back an object that belongs to another user.
Tenant isolation
Any path, direct or indirect, that lets one customer read or change another customer's data.
Authentication and sessions
Token issue and expiry, logout that does not end the session, and MFA that can be skipped.
Authorization bypass
Checks enforced in the interface but not on the server, or on one endpoint but not its sibling.
Business logic
Workflows used in an order the product never intended, such as skipping a payment or approval step.
Privilege escalation
Users raising their own role or editing the fields that decide what they are allowed to do.
Account lifecycle and recovery
Invitations, email changes, password reset and deletion, where ownership is often checked once and never again.
Sensitive data exposure
Responses that return more than the screen shows, such as internal fields or other users' details.
Race conditions
Parallel requests that redeem, transfer or approve something more times than the rules allow.
Scanners miss these because nothing in the response looks wrong. A request for another customer's invoice returns a normal invoice. Only someone who knows whose invoice it should be can tell it is a breach, and that takes several accounts and knowledge of who owns what.
Process
How an Engagement Runs
The same six steps apply to every service below. A focused security review takes three to five business days, and a deep security assessment one to two weeks.
01
Scoping
You and I agree which product areas, roles, APIs and integrations are in scope, and what must not be touched. The scope is then written down.
02
Access setup
You provide test accounts for each role and any API documentation. I confirm access works before testing starts.
03
Testing
Manual testing against the agreed scope. A critical finding is reported as soon as it is confirmed, not held for the report.
04
Reporting
A written report of every confirmed finding, described below.
05
Remediation support
I answer engineering questions while fixes are built, so each fix addresses the root cause rather than the one example reported.
06
Retest
After fixes are deployed, I retest the reported findings and confirm which are closed.
Deliverable
What You Receive
Every finding comes with the steps to reproduce it, a proof of concept, an analysis of what an attacker could actually reach, and remediation guidance specific to your code and architecture. The report is written for the engineers who will fix the issues, with a summary a manager can read without the technical detail.
Two sanitized examples are public, so you can see the format and depth before you ask for a scope: a sample SaaS penetration test report and a sample access control assessment report.
Choosing
Which Service Fits Your Situation
You are about to ship, or just have
You need to know whether access control, authentication and business logic hold up against a real attacker.
Penetration testing →Customers or partners call your API directly
Your REST or GraphQL backend is reachable without your frontend, so its own checks are the only ones that count.
API security testing →You do not know what of yours is exposed
Old subdomains, forgotten staging environments and services nobody owns any more are still on the internet.
Asset monitoring →You have a scanner backlog nobody trusts
You need to know which findings are real and which to fix first.
Vulnerability assessment →You are preparing for a SOC 2 audit
You need a penetration test scoped around your audit and mapped to Trust Services Criteria.
SOC 2 penetration testing →Scopes
How Services Map to Product Risk
Use individual service pages for deeper scope details, or start with a focused security review when the highest-risk area is not yet clear.
Service
View Review ScopePenetration Testing
Manual application security testing across authentication, session handling, access control, business logic, and high-risk user journeys.
Service
View Review ScopeAsset Monitoring
External attack surface monitoring for exposed services, subdomains, endpoints, and assets that expand SaaS platform risk.
Service
View Review ScopeVulnerability Assessment
Vulnerability assessment that separates real attack paths from noise so teams can prioritize fixes with confidence.
Service
View Review ScopeSecurity Reviews
Founder-led review windows for releases, launch readiness, API changes, access control models, and customer-impacting workflows.
Ongoing work
Retainers
Ongoing engagements are available on request. If you want testing to continue past a single engagement, say so when you get in touch.
Next step
Request a Security ReviewValidate the product paths that matter most.
Share the product area, API surface, or release window you want reviewed. The scope can stay narrow and practical.
- Request
- Scope discussion
- Recommended review
- Testing