Web applications
Authenticated and unauthenticated workflows, authorization boundaries, session handling, input processing, business logic, and browser-facing controls.
Find the paths an attacker would take.
Human-led penetration testing for web applications, APIs, and LLM-enabled products. You get reproducible evidence, a clear explanation of business impact, and remediation guidance your team can put to work.
Testing begins only after written authorization, an agreed scope, and rules of engagement.
What can be tested
Focused on how your product actually works
The test plan is shaped around your architecture, users, trust boundaries, and highest-value workflows, not a generic scanner checklist.
APIs and integrations
Object- and function-level authorization, authentication, data exposure, rate and resource controls, webhook trust, and integration assumptions.
LLM-enabled products
Prompt and context boundaries, sensitive information disclosure, unsafe output use, retrieval and supply-chain risk, tool access, and excessive agency.
Methodology
Standards-led, context-aware testing
Recognized guidance provides coverage and repeatability. Manual investigation connects individual weaknesses into realistic attack paths and keeps the work relevant to your environment.
Plan the engagement
Objectives, in-scope systems, test accounts, exclusions, timing, data handling, communication, stop conditions, and incident contacts are documented in rules of engagement aligned with NIST SP 800-115.
Map and test the application
The current stable OWASP Web Security Testing Guide 4.2 informs coverage across identity, authorization, sessions, input handling, business logic, client-side behavior, and APIs.
Exercise AI-specific trust boundaries
Where LLMs or agents are in scope, testing uses the current OWASP GenAI LLM Top 10 2026 to examine prompt injection, information disclosure, insecure dependencies, unsafe output handling, tool use, permissions, and resource abuse.
Validate and score findings
Potential issues are manually validated before reporting. Technical severity is communicated with a CVSS 4.0 score and vector, then paired with application-specific impact and practical remediation priority.
Tools support the work; they do not define it.
Automation helps with discovery and repeatability. Findings are reviewed by a person, and destructive techniques are excluded unless they are explicitly approved.
Deliverables
A report built for decisions and fixes
The result should be useful to the people setting priorities and to the engineers doing the remediation.
- Executive summaryScope, overall posture, material risks, and prioritized next steps.
- Technical findingsReproduction steps, evidence, affected components, impact, and remediation guidance.
- Transparent severityCVSS 4.0 score and vector alongside business and environmental context.
- Readout and retestA findings review with your team and validation of agreed remediated issues.
About the tester
A builder's perspective on security
I came into security through systems and infrastructure. That start taught me to look past the application itself and ask what it depends on, who trusts it, and what happens when those assumptions fail. For more than 13 years, my work has moved through telecommunications, DevSecOps, detection and response, security architecture, and technical leadership. Much of it has stayed close to the machinery of the internet: email, domains, certificates, identity, and cloud platforms serving millions of customers.
I enjoy the problems that sit between security and engineering. They rarely have a neat checklist answer. My work has often meant untangling legacy constraints, following incidents across system boundaries, and building controls or automation that teams can actually operate. The common thread is making complicated risk visible and giving people clear evidence they can act on.
I founded NOB.center out of one of those gaps. I needed a continuous view of the trust plane around internet domains, including Certificate Transparency, live certificate deployment, DNS, and RDAP, but could not find a product that connected those signals. Building it brought together the parts of security I care about most: understanding how systems behave, finding the gaps between them, and turning evidence into useful action.
Start with the scope
Tell me what you need tested.
Share the application type, the important workflows, your target window, and whether APIs or LLM features are in scope.