of professional developers use AI tools every day
Stack Overflow Developer Survey 2025AI-assisted teams ship more code. Independent security review must keep pace.
Defence independently tests live web applications and APIs. We examine business logic and access boundaries, support confirmed findings with redacted evidence, and state what was not reproduced, blocked, or outside scope.
Excerpt from the review mapsample output
User data isolationIssue confirmedRedacted request and response
Administrative routesNot reproducedRecorded roles and tested scenarios
Payment integrationBlockedNo safe test environment
Third-party identity providerOut of scopeAsset is controlled by a third party
Send the primary domain from your work email. We begin with a manually prepared passive snapshot of permitted public sources and intentionally public pages. Active testing starts only after separate written authorization.
More releases create more behavior to verify
AI tools are now part of ordinary development work. When a team ships more changes, there are more routes, roles, integrations, and business workflows to recheck. Senior review capacity does not automatically expand with release volume.
of breaches in the DBIR sample began with exploitation of vulnerabilities
Verizon DBIR 2026These figures do not show that AI use causes vulnerabilities or that AI-assisted developers produce lower-quality code. They establish two separate facts: AI tools are widely used, and exploitation of software vulnerabilities remains a real route into systems.
How Defence investigates a live product
The model proposes hypotheses, techniques, and pivots. A separate Defence control plane preserves the known system map, evidence lineage, test conditions, blockers, and unresolved work.
- 01
Builds a map of the observed system
Connects discovered domains, routes, APIs, roles, objects, user journeys, and integrations. A list of found pages is not treated as a complete map of the product.
- 02
Turns product rules into testable hypotheses
Records the data each role should see, the actions it should be able to take, and the required workflow order. It checks whether the interface and API enforce the same rules. The model selects the next hypothesis and test method.
- 03
Tests behavior, not just signatures
OWASP WSTG, OWASP API Security Top 10, CWE, HackTricks, CVE references, and tool output guide the investigation. They are not evidence of complete coverage. A suspected break is either demonstrated, not reproduced under recorded conditions, blocked by a specific constraint, or left outside scope.
- 04
Requires evidence for a finding
A tool alert is a signal, not a finding. It becomes a finding only after Defence reproduces an observable property break, identifies the affected surface, and preserves the minimum necessary redacted evidence.
- 05
Records what remains unresolved
An empty checklist or model confidence is not completion. Before closing, two fresh review passes challenge the map, the evidence, and the remaining unknowns.
- Scope recorded
- Findings require evidence
- Unknowns stay unknown
What Defence tests
The plan follows the observed product, not a universal checklist. For every applicable area, we record the scenarios, test conditions, and current result.
Identity and sessions
Tests whether login, recovery, MFA, logout, cookies, sessions, and JWTs enforce the intended identity and session boundaries.
- authentication bypass
- recovery and MFA
- cookies, sessions, and JWTs
Access control and tenant isolation
Compares owned test accounts and roles to see whether one principal can read or change objects reserved for another.
- IDOR and BOLA
- role bypass
- privilege escalation
Business logic and workflows
Tests sequence, state, quota, plan entitlement, approval, and concurrent-action rules using synthetic objects.
- step bypass
- state errors
- race conditions
Input and server-side behavior
Uses bounded payloads to examine request handling for injection, XSS, SSRF, file and path flaws, template injection, and unsafe HTTP parsing.
- injection and XSS
- SSRF and file handling
- headers and request desync
APIs and integrations
Builds an endpoint inventory and tests object and property authorization, sensitive business flows, webhooks, OAuth, and trust in connected APIs.
- object and property authorization
- hidden and legacy endpoints
- OAuth, webhooks, and external APIs
Configuration and external exposure
Reviews public admin, debug, and API docs, CORS, caching, TLS, errors, client assets, and identifiable component versions. A CVE match remains a lead until it reproduces.
- configuration exposure
- CORS, caching, and TLS
- component and CVE signals
Method references
OWASP WSTG, OWASP API Security Top 10, CWE, CVE, and HackTricks supply testing lenses. They do not replace the product map or prove that a review is complete.
What the team gets
The report contains a reproduced property break, not a scanner notification.
We identify the roles, objects, endpoints, conditions, and minimum redacted evidence involved.
The team sees practical impact, constraints, and the next verifiable step, not severity alone.
Tests with no reproduced break, blockers, out-of-scope areas, and unknowns remain explicit.
Effect boundary
Real customer and financial data stay outside the proof path
By default, the external review uses dedicated test accounts and synthetic objects. Real customer data is not test material: we do not intentionally open, change, copy, or retain it.
We use agreed accounts, roles, records, and sandbox integrations. Payment flows are tested only in an approved test mode, without moving real money; otherwise the area is marked blocked.
We stop a branch after the first sufficient confirmation. We do not enumerate adjacent objects, export datasets, or expand impact to make the result look stronger.
If a real customer record, secret, session, or financial detail appears, that branch stops. We notify the named contact and do not continue access.
We retain the minimum: request metadata, the necessary fragment, a local hash, or a synthetic label. Passwords, tokens, cookies, and third-party record contents stay out of the report.
Outside this external review
- DoS, load testing, or intentional availability degradation
- social engineering, phishing, or broad testing of real credentials
- malware, persistence, backdoors, or destructive changes
- real payments, refunds, transfers, or messages to customers
- third-party assets without separate owner authorization
- source code, internal networks, or cloud configuration
If a potentially affecting test is needed, it is not added silently. It requires a separate scope, written approval, a safe environment, an effect limit, and a rollback plan.
What was actually tested
Defence does not label a product secure. Each material investigation area in the research record receives a current state.
DirectionResultBasisNext step
User data isolation
Issue confirmed
Redacted request and response
Correct the object ownership check
Administrative routes
Not reproduced
Recorded roles and tested scenarios
Retest when roles change
Payment integration
Blocked
No safe test environment
Provide an approved test scenario
Third-party identity provider
Out of scope
Asset is controlled by a third party
Obtain written permission from the owner
Demo only: this table is a planned client view, not a real customer result. Defence's technical register already records these states; the client report format is still in development.
If no vulnerability is reproduced, the result still records the observed surface, tested conditions, blockers, out-of-scope areas, and unknowns. The record supports the next decision but does not certify safety or complete coverage.
How an engagement starts
- 01
Passive external snapshot
After checks on jurisdiction, sector, and asset ownership, we manually gather signals from permitted public and historical sources. No active testing takes place; the snapshot is not a penetration test.
- 02
Written authorization
We record the exact assets, methods, time window, effect limits, and emergency contact. An enquiry or call is not authorization.
- 03
Authorized testing
We test only the authorized external web/API surface: one submitted URL and same-site assets explicitly attached to the written scope. Work on a branch stops if it exposes third-party data, secrets, or signs of instability.
- 04
Results and targeted retest
We deliver confirmed findings, tests where no property break was reproduced, blockers, out-of-scope areas, and unknowns. A separately agreed retest answers only whether a named finding remains after remediation.
Availability of the snapshot and active testing depends on jurisdiction, sector, asset ownership, and compliance review.
Complements the existing security stack
Scanners
Scanners produce leads. Defence tests whether they reproduce under agreed conditions and what observable property break follows.
Code review
Code review examines implementation. Defence tests the behavior of the deployed product through the authorized external surface.
Retest
A separately scheduled retest checks whether one named finding still reproduces after remediation. It is not continuous monitoring.
Before testing starts
Can testing affect a live product?
Before testing, we agree the methods, effect limits, stop conditions, and emergency contact. Actions that may affect the product require specific approval. No one can promise zero risk, so the written authorization includes stop rules.
Will Defence touch customer data or real payments?
Not as a planned test path. We use owned test accounts, synthetic records, and integration test modes. If real customer or financial data, or a secret, appears unexpectedly, we stop that branch, do not enumerate further, and retain only the minimum redacted evidence.
What data can language models process?
The selected model provider may process product responses needed for the investigation. Before work starts, we disclose the provider, retention mode, processing region, and contractual restrictions. Passwords, session cookies, one-time codes, magic links, and other secrets must not be copied into Defence's persistent state or client report. Any provider-side traces follow the disclosed provider terms and retention mode.
Do you need source code access?
Source code access is not required for this external service. Defence tests the deployed web application or API. Source code, internal networks, and cloud configuration are outside scope.
Who is accountable for the service?
Service owner: Vlad Kuklev. Before work starts, Defence records the contracting party, applicable jurisdiction, selected model providers, retention mode, processing region, and data-handling terms.
See what is visible from the public internet
Start with a manually prepared passive snapshot of permitted public sources. It does not include active testing and does not commit the company to further work.
Request a free passive snapshotDefence does not promise complete coverage, discovery of every vulnerability or zero-day, or absence of risk. Conclusions apply only to the authorized assets, methods, conditions, and time window.