01
Test object ownership
Check whether users can read, modify or delete objects they do not own.
API penetration testing
Test whether the API enforces ownership, privilege and business rules on every request.
Damocles API Penetration Testing assesses authentication, object-level authorisation, role enforcement, workflow abuse, rate controls, data exposure and unsafe server-side behaviours across approved REST, GraphQL or other application interfaces.
REST and GraphQL APIsObject and role authorisationWorkflow and rate abuseRequest-level evidence
Why customers buy this test
Test the security boundary behind connected applications.
Modern applications often expose their most sensitive operations through APIs. A secure client interface does not help if the API accepts another user’s object identifier, trusts client-supplied roles, exposes excessive data or permits a workflow to be repeated or reordered.
Damocles tests the API as a security boundary in its own right using approved identities, objects and workflows. Where useful, API testing can be combined with the web or mobile client that consumes it.
02
Test role enforcement
Validate that privileged operations remain protected at the API rather than only in the client.
03
Test workflow abuse
Assess sequence, replay, limit, mass-action and state-manipulation conditions that can create business impact.
What we test
API endpoints, identities, objects, roles and business workflows in the approved interface.
API documentation, representative accounts, object data and a stable test environment materially improve coverage.
AU
Authentication
Tokens, keys, sessions, service credentials, refresh flows and authentication boundary behaviour.
OB
Object authorisation
Ownership, record access, tenant separation and object-level permissions.
FN
Function authorisation
Administrative, privileged and role-restricted operations exposed through API functions.
DT
Data exposure
Excessive response data, unsafe fields, hidden attributes and sensitive information leakage.
WF
Workflow and state
Order, replay, duplicate action, approval, limit and state-transition abuse.
RC
Rate and resource controls
Rate limits, resource consumption and abuse conditions where safe and expressly authorised.
Technical assurance
Test the controls protecting API data and functions.
Test API endpoints across unauthenticated, authenticated, cross-role and integration contexts to expose access-control, token, input and workflow weaknesses.
Endpoint inventory
Documented, hidden and versioned endpoints exposed by the service.
Object authorisation
Whether identities can reach another user or tenant’s records.
Function and property access
Restricted operations and sensitive fields across roles.
Tokens and keys
Issuance, scope, expiry, replay and revocation controls.
Input processing
Injection, unsafe parsing, mass assignment and schema handling.
Business workflows
Sequence bypass, replay and misuse of legitimate operations.
Rate and resource controls
Abuse resistance for quotas, concurrency and expensive operations.
Integrations and logging
Webhook trust, downstream boundaries and traceable security events.
What we actually test
Jump to full coverage matrix ↓Representative technical coverage with the evidence produced.
These are governed procedures from the service assurance profile—not generic marketing categories. The complete matrix below records applicability, access requirements and limitations for every coverage area.
Interface and version inventory
Damocles enumerates documented and observed API routes, methods and versions and reconciles them with the supported interface inventory.
Authentication
Damocles tests client and user authentication, token acquisition, unauthenticated requests, failure responses and error behaviour across approved authentication mechanisms.
Token and key lifecycle
Damocles follows token and key issuance, scopes, audience, storage, expiry, rotation, revocation and replay using representative authenticated clients.
Object-level authorisation
Damocles changes representative object identifiers between controlled identities and tenants and compares the server-side access decision.
Property-level authorisation
Damocles submits and retrieves fields that the current role should not set or view and records whether property-level policy is enforced.
Function-level authorisation
Damocles invokes approved privileged functions with lower-privilege tokens and compares the response with the expected function-level policy.
Showing 6 representative areas. The full governed matrix contains 16 coverage areas.
Standards and assurance coverage
See how this engagement is structured, classified and mapped before opening the full evidence matrix.
References are shown according to the role they play in the engagement. Methodologies guide testing, taxonomies classify findings, severity methods support consistent scoring, and control mappings connect scoped evidence to broader assurance work.
How testing is structured
Approved methodology, verification and testing guidance used to select and structure relevant procedures within the authorised scope.
How weaknesses and severity are classified
Approved risk, weakness and severity references provide a consistent language for confirmed findings without replacing customer-specific business impact.
What maps into compliance and assurance work
11governed evidence mappings across 7 approved frameworks and 8 referenced controls.
3 directly assessed4 supporting evidence4 contextual
Security and Privacy Controls for Information Systems and Organizations Release 5.2.0Directly assessed
AC-3
Tests server-side object, property, function and tenant authorisation using representative controlled identities, tokens and records.
Security and Privacy Controls for Information Systems and Organizations Release 5.2.0Directly assessed
SC-8
Tests whether in-scope API endpoints protect traffic in transit through observed HTTPS, certificate and protocol enforcement.
Security and Privacy Controls for Information Systems and Organizations Release 5.2.0Directly assessed
SI-10
Tests representative API parameters, schemas, request bodies, files and parser boundaries for server-side input validation and unsafe processing.
+ 8 additional governed mappings in the full control matrix.
Jump to full control mapping ↓What the customer can use after the engagement
A prioritised API report with reproducible requests, affected objects or roles, remediation guidance and retest results.
- Authorised scope and rules of engagement
- Coverage matrix
- Retest and residual-risk record
- + 3 additional controlled outputs
What this means: technical evidence may support risk, compliance and audit activity where the mapping is applicable. It does not by itself certify the organisation, establish complete compliance or assess controls outside the authorised scope.
Manual validation backed by controlled evidence.
Damocles inventories interfaces and exercises representative API clients across roles and tenants, retaining request-and-response pairs for authorisation, state and resource-control decisions. Design evidence informs but does not substitute for runtime checks; unsafe volume and destructive operations are excluded.
Evidence is mapped to the part of a control we can actually assess.
Directly assessed means the engagement tests the relevant behaviour. Supporting evidence means the result can contribute to a broader control assessment. Contextual references explain relevance without claiming that the control was tested.
All relevant frameworks
Web Security Testing Guide 4.2Application Security Verification Standard 5.0.0OWASP API Security Top 10 2023Common Weakness Enumeration 4.20Common Vulnerability Scoring System 4.0Security and Privacy Controls for Information Systems and Organizations Release 5.2.0Information Security Manual June 2026Prudential Standard CPS 234 Information Security effective 1 July 2019Prudential Practice Guide CPG 234 Information Security published June 2019ISO/IEC 27001 2022 with Amendment 1:2024ISO/IEC 27002 2022Payment Card Industry Data Security Standard 4.0.1
Testing perspectives6 authorised viewpoints and access models
Unauthenticated API client
Discovers approved interfaces and sends requests without credentials to observe public and authentication-failure behaviour.
Standard authenticated API client
Calls representative operations with an ordinary client or user token and records server-side decisions.
Cross-role or cross-tenant API identities
Replays equivalent API operations across controlled roles or tenants while exchanging object and property values.
Privileged API client
Invokes approved administrative operations with a dedicated privileged token and compares lower-privilege outcomes.
Integration client
Exercises approved webhook, callback and upstream-integration paths using controlled secrets and messages.
Architecture-assisted reviewer
Compares observed routes, schemas and controls with API specifications, gateway policy and data-flow evidence.
Exact test coverage and evidence16 governed coverage areas
| Coverage area | What Damocles tests | Perspective and access | Evidence produced | References and limits |
|---|---|---|---|---|
| Interface and version inventory | Damocles enumerates documented and observed API routes, methods and versions and reconciles them with the supported interface inventory. | Architecture-assisted reviewer Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for interface and version inventory. | Evidence records the API request, response, token, object state or gateway evidence relevant to interface and version inventory. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Interface and version inventory when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled interface and version inventory; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| Authentication | Damocles tests client and user authentication, token acquisition, unauthenticated requests, failure responses and error behaviour across approved authentication mechanisms. | Standard authenticated API client Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for authentication. | Evidence records the API request, response, token, object state or gateway evidence relevant to authentication. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Authentication when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled authentication; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| Token and key lifecycle | Damocles follows token and key issuance, scopes, audience, storage, expiry, rotation, revocation and replay using representative authenticated clients. | Standard authenticated API client, Architecture-assisted reviewer Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for token and key lifecycle. | Evidence records the API request, response, token, object state or gateway evidence relevant to token and key lifecycle. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Token and key lifecycle when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled token and key lifecycle; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| Object-level authorisation | Damocles changes representative object identifiers between controlled identities and tenants and compares the server-side access decision. | Standard authenticated API client, Cross-role or cross-tenant API identities Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for object-level authorisation. | Evidence records the API request, response, token, object state or gateway evidence relevant to object-level authorisation. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Object-level authorisation when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled object-level authorisation; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| Property-level authorisation | Damocles submits and retrieves fields that the current role should not set or view and records whether property-level policy is enforced. | Standard authenticated API client, Cross-role or cross-tenant API identities Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for property-level authorisation. | Evidence records the API request, response, token, object state or gateway evidence relevant to property-level authorisation. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Property-level authorisation when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled property-level authorisation; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| Function-level authorisation | Damocles invokes approved privileged functions with lower-privilege tokens and compares the response with the expected function-level policy. | Standard authenticated API client, Cross-role or cross-tenant API identities Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for function-level authorisation. | Evidence records the API request, response, token, object state or gateway evidence relevant to function-level authorisation. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Function-level authorisation when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled function-level authorisation; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| Tenant separation | Damocles exchanges tenant-owned identifiers and context between at least two controlled tenants to test isolation of data and operations. | Standard authenticated API client, Cross-role or cross-tenant API identities Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for tenant separation. | Evidence records the API request, response, token, object state or gateway evidence relevant to tenant separation. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Tenant separation when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled tenant separation; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| Excessive data exposure | Damocles compares documented response schemas with fields returned to representative roles and identifies unnecessary sensitive data exposure. | Unauthenticated API client Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for excessive data exposure. | Evidence records the API request, response, token, object state or gateway evidence relevant to excessive data exposure. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Excessive data exposure when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled excessive data exposure; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| Mass assignment and unsafe property binding | Damocles adds protected, immutable or server-managed properties to create and update operations and observes binding and validation behaviour. | Unauthenticated API client Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for mass assignment and unsafe property binding. | Evidence records the API request, response, token, object state or gateway evidence relevant to mass assignment and unsafe property binding. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Mass assignment and unsafe property binding when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled mass assignment and unsafe property binding; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| Workflow and state manipulation | Damocles reorders, skips or repeats required API state transitions using disposable records and compares the resulting state with workflow rules. | Standard authenticated API client Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for workflow and state manipulation. | Evidence records the API request, response, token, object state or gateway evidence relevant to workflow and state manipulation. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Workflow and state manipulation when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled workflow and state manipulation; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| Replay and duplicate operations | Damocles safely replays representative transactions and duplicate messages to assess idempotency, duplicate processing and state consistency. | Unauthenticated API client Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for replay and duplicate operations. | Evidence records the API request, response, token, object state or gateway evidence relevant to replay and duplicate operations. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Replay and duplicate operations when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled replay and duplicate operations; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| Rate and resource controls | Damocles sends bounded request rates and safe resource parameters to assess throttling, quotas, pagination, concurrency, costly operations and resource limits. | Unauthenticated API client Approved endpoints, dedicated clients, bounded request-rate ceilings, safe pagination and resource parameters, and expected quota behaviour. | API request timing, response status and headers, quota state and resource-consumption observations at each approved rate. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies where API rate, quota, pagination, concurrency or expensive-operation controls are implemented and safe to sample. Limit: Traffic remains below approved ceilings; results do not establish capacity under denial-of-service or sustained production load. |
| Deprecated and shadow interfaces | Damocles compares discovered routes and versions with the supported inventory and safely checks deprecated, undocumented or shadow interfaces. | Unauthenticated API client Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for deprecated and shadow interfaces. | Evidence records the API request, response, token, object state or gateway evidence relevant to deprecated and shadow interfaces. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Deprecated and shadow interfaces when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled deprecated and shadow interfaces; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| Unsafe consumption of third-party APIs | Damocles reviews validation and trust applied to data received from approved upstream integrations without interacting with or testing the provider itself. | Unauthenticated API client Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for unsafe consumption of third-party APIs. | Evidence records the API request, response, token, object state or gateway evidence relevant to unsafe consumption of third-party APIs. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Unsafe consumption of third-party APIs when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled unsafe consumption of third-party APIs; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| Webhooks and callbacks | Damocles tests webhook signatures, authenticity, replay, callback destinations, retry behaviour and tenant or object association using controlled messages. | Unauthenticated API client Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for webhooks and callbacks. | Evidence records the API request, response, token, object state or gateway evidence relevant to webhooks and callbacks. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to Webhooks and callbacks when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled webhooks and callbacks; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
| GraphQL behaviour | Damocles tests introspection, field and resolver authorisation, query depth and complexity, batching and aliases within safe limits when GraphQL is present. | Unauthenticated API client Assessment requires approved endpoints, specifications, controlled clients, representative objects and expected role or tenant behaviour, selected specifically for graphql behaviour. | Evidence records the API request, response, token, object state or gateway evidence relevant to graphql behaviour. | Web Security Testing Guide 4.2 · WSTG-v42-APIT Applicability: Applies to GraphQL behaviour when the operation and required representative identities or integration are in scope. Limit: The conclusion is limited to the sampled graphql behaviour; results cover supplied clients, objects and bounded rates; destructive or provider-side testing is excluded. |
Framework and control mappings11 governed evidence mappings
| Framework and controls | Mapping type | What Damocles assesses | Evidence produced | Applicability and limits |
|---|---|---|---|---|
| Security and Privacy Controls for Information Systems and Organizations Release 5.2.0 AC-3 | Directly assessed | Tests server-side object, property, function and tenant authorisation using representative controlled identities, tokens and records. | Reproducible API requests and responses, token and role context, representative object identifiers and expected-versus-observed access decisions. | Applies: Applies where representative identities, tenants, objects or restricted functions are included in scope. Limit: The conclusion is limited to sampled identities, objects, functions and tenants and does not establish complete organisational access-control implementation. |
| Security and Privacy Controls for Information Systems and Organizations Release 5.2.0 SC-8 | Directly assessed | Tests whether in-scope API endpoints protect traffic in transit through observed HTTPS, certificate and protocol enforcement. | Connection and protocol observations, certificate evidence and affected endpoint records. | Applies: Applies to approved API transport paths that can be exercised safely. Limit: Does not assess every system-to-system path, cryptographic key-management process or continuous transport configuration. |
| Security and Privacy Controls for Information Systems and Organizations Release 5.2.0 SI-10 | Directly assessed | Tests representative API parameters, schemas, request bodies, files and parser boundaries for server-side input validation and unsafe processing. | Representative payloads, requests and responses, schema or parser behaviour and reproducible finding evidence. | Applies: Applies to reachable input and parsing paths expressly included in the API scope. Limit: Sampling cannot establish equivalent validation for every parameter, schema, parser, code path or downstream component. |
| Security and Privacy Controls for Information Systems and Organizations Release 5.2.0 AU-2AU-3 | Supporting evidence | Where logs are supplied, generates representative authentication, authorisation, error and workflow events and checks whether tested actions can be traced. | Timestamped API actions correlated to supplied event records and available identity, source, outcome and security context. | Applies: Applies only when relevant application, gateway or security logging is in scope and accessible for correlation. Limit: Does not establish the customer's event-selection policy, complete audit-record content, retention, review process or continuous monitoring coverage. |
| Security and Privacy Controls for Information Systems and Organizations Release 5.2.0 CA-8 | Supporting evidence | Performs an authorised point-in-time API penetration test across agreed unauthenticated, authenticated, cross-role, cross-tenant and integration perspectives. | Rules of engagement, coverage matrix, reproducible findings, request-and-response evidence, remediation guidance and retest results where included. | Applies: Relevant where the customer uses API penetration testing within a broader assessment program. Limit: Does not establish organisation-defined testing frequency, enterprise coverage, assessor governance or completeness of the broader program. |
| Information Security Manual June 2026 ISM-2118 | Supporting evidence | Provides scoped API penetration-test evidence that can support an organisation's security-assurance testing program. | Authorised scope, API coverage and request-response evidence, findings, remediation guidance and retest results where included. | Applies: Relevant where the organisation uses the engagement as one input to its vulnerability-assessment and penetration-testing program. Limit: A single engagement does not establish required testing cadence, full system coverage or compliance with ISM-2118. |
| Prudential Standard CPS 234 Information Security effective 1 July 2019 CPS 234 paragraph 27 | Supporting evidence | Produces scoped API penetration-testing evidence that may support an APRA-regulated entity's systematic testing of information-security control effectiveness. | Governed scope, API request-and-response evidence, findings, remediation guidance and retest results where included. | Applies: Relevant only where the customer determines that the assessed API, systems and evidence are applicable to its assurance or compliance scope. For APRA-regulated entities, the customer determines how the engagement contributes to its broader systematic control-testing program. Limit: A scoped engagement does not by itself establish the customer's systematic testing program, testing frequency, full control population, specialist independence, governance, reporting or compliance with other CPS 234 requirements. |
| Prudential Practice Guide CPG 234 Information Security published June 2019 Framework-level context | Contextual | Produces scoped API penetration-testing evidence consistent with CPG 234 guidance that testing techniques should be selected for the control and risk being assessed. | Governed scope, API request-and-response evidence, findings, remediation guidance and retest results where included. | Applies: Relevant only where the customer determines that the assessed API, systems and evidence are applicable to its assurance or compliance scope. APRA-regulated customers determine how this evidence contributes to their broader assurance program. Limit: CPG 234 is prudential guidance rather than a standalone certification target; this mapping does not claim assessment of the complete guidance or customer compliance. |
| ISO/IEC 27001 2022 with Amendment 1:2024 Framework-level context | Contextual | Produces scoped API penetration-testing evidence that may support customer assurance activities organised around ISO/IEC 27001 where the assessed systems and behaviours are relevant. | Governed scope, API request-and-response evidence, findings, remediation guidance and retest results where included. | Applies: Relevant only where the customer determines that the assessed API, systems and evidence are applicable to its assurance or compliance scope. Limit: Licensed ISO/IEC 27001 control or requirement identifiers and text are intentionally withheld. The engagement does not establish ISO/IEC 27001 certification, attestation or whole-framework conformity. |
| ISO/IEC 27002 2022 Framework-level context | Contextual | Produces scoped API penetration-testing evidence that may support customer assurance activities organised around ISO/IEC 27002 where the assessed systems and behaviours are relevant. | Governed scope, API request-and-response evidence, findings, remediation guidance and retest results where included. | Applies: Relevant only where the customer determines that the assessed API, systems and evidence are applicable to its assurance or compliance scope. Limit: Licensed ISO/IEC 27002 control or requirement identifiers and text are intentionally withheld. The engagement does not establish ISO/IEC 27002 certification, attestation or whole-framework conformity. |
| Payment Card Industry Data Security Standard 4.0.1 Framework-level context | Contextual | Produces scoped API penetration-testing evidence that may support customer assurance activities organised around PCI DSS where the assessed systems and behaviours are relevant. | Governed scope, API request-and-response evidence, findings, remediation guidance and retest results where included. | Applies: Relevant only where the customer determines that the assessed API, systems and evidence are applicable to its assurance or compliance scope. Limit: Licensed PCI DSS control or requirement identifiers and text are intentionally withheld. The engagement does not establish PCI DSS certification, attestation or whole-framework conformity. |
Assurance boundary: Damocles maps assessed coverage and findings to agreed security frameworks and control objectives. This provides traceable technical evidence that may support risk, assurance and audit activities. A penetration test does not by itself certify an organisation, establish complete compliance with a framework or confirm the effectiveness of controls outside the authorised scope.
Report and evidence outputs6 controlled output types
Authorised scope and rules of engagement
Records authorised scope and rules of engagement produced from the authorised API penetration testing work.
Coverage matrix
Records coverage matrix produced from the authorised API penetration testing work.
Retest and residual-risk record
Records retest and residual-risk record produced from the authorised API penetration testing work.
API request-and-response evidence
Records API request-and-response evidence produced from the authorised API penetration testing work.
Object and tenant coverage matrix
Records object and tenant coverage matrix produced from the authorised API penetration testing work.
Token and workflow evidence
Records token and workflow evidence produced from the authorised API penetration testing work.
What you receive
A prioritised API report with reproducible requests, affected objects or roles, remediation guidance and retest results.
Attack paths we look for
API attack paths that bypass ownership, role and workflow controls.
The assessment follows the API data model and business operations rather than testing endpoints in isolation.
BO
Broken object-level authorisation
Access to another user or tenant object through manipulated identifiers or missing checks.
BF
Broken function authorisation
Calling privileged functions from a lower-privilege identity or untrusted context.
MA
Mass assignment
Changing fields or properties the client should not be allowed to control.
ED
Excessive data exposure
Responses that disclose unnecessary or sensitive attributes beyond the caller’s need.
WF
Workflow abuse
Reordering, replaying or repeating requests to bypass business rules.
TK
Token and session abuse
Weak token validation, lifecycle or audience controls that create unintended access.
Engagement options
Scope API testing by interface, role, client and business workflow.
The statement of work identifies API versions, environments, accounts, object sets, rate constraints and high-risk operations.
RS
REST API assessment
Assess approved REST endpoints, identities, resources and business operations.
GQ
GraphQL assessment
Assess queries, mutations, schema exposure, object access and authorisation behaviour.
AU
Role-based API testing
Use multiple approved identities to validate object and function separation.
CI
Client + API assessment
Combine web or mobile testing with the API that actually performs the operation.
RT
API retest
Reproduce agreed requests and abuse paths after remediation.
What you receive
Request-level evidence showing exactly which API control failed and how to correct it.
Findings identify endpoint, identity, object, request, response and business consequence.
ES
Executive API risk
Material identity, data and workflow exposure explained in customer terms.
RQ
Requests and responses
Reproducible request and response evidence for material findings.
ID
Identity and role context
Caller role, object ownership and expected permission boundary for the affected operation.
TF
Technical findings
Affected endpoint, condition, impact and remediation guidance.
RP
Remediation guidance
Specific server-side authorisation, validation, data-minimisation or workflow-control improvements.
RR
Retest evidence
Verification of agreed API fixes using the same request and identity conditions.
Remediation and retesting
API retesting uses the original identity, object and request condition to verify the server-side fix.
Damocles reproduces agreed API findings after remediation and records whether the original call is correctly rejected or constrained.
New versions, endpoints and materially changed workflows are treated as new scope where they go beyond the original assessed interface.
Testing delivery
A controlled technical engagement without turning the service page into a methodology manual.
The commercial scope comes first. Delivery is then controlled through written authority, agreed safety boundaries and a clear retest path.
01
Scope and authorise
Confirm targets, ownership, attacker perspective, accounts, exclusions, timing, contacts and prohibited activity.
02
Test and validate
Perform the authorised manual and technical testing required to prove or disprove the attack paths in scope.
03
Report and brief
Provide evidence, impact, affected scope, remediation priorities and a technical walkthrough with the people responsible for the fix.
04
Retest
Reproduce agreed findings after remediation and record whether they are resolved, reduced or still exploitable.
Scope boundaries
API testing covers the agreed interfaces and identities; connected clients and infrastructure are separate unless included.
Web, mobile, source-code, cloud and infrastructure testing can be combined with API testing where the customer needs broader end-to-end coverage.
Resource-exhaustion and aggressive rate testing are controlled or excluded unless expressly authorised because they can affect production availability.
Scope the right test
Give us the API documentation, environments, roles and high-risk operations you need assessed.
We will define the interfaces, identities, object sets, workflows, safety controls and retest allowance required.