API security assessment report
Report classification
| Field | Value |
|---|---|
| Assessment type | Internal, non-invasive API security assessment |
| Target | Browser-facing managed APIs, trusted serverless operations, database operations, and provider callbacks supporting FinTrack |
| Evidence | Application implementation, active managed-service inventory, read-only security advisories, and authoritative provider guidance |
| Standards baseline | OWASP API Security Top 10:2023, OWASP ASVS 5.0.0, OWASP WSTG 4.2, and CVSS 4.0 principles |
| Independence | Not independently performed or certified by an external penetration-testing organisation |
| Overall result | Open risk remains; authorised dynamic API testing is required |
This report records the latest internal assessment. It is not an independent API penetration test, does not claim full endpoint coverage, and is not proof of OWASP ASVS conformance.
Executive summary
The assessment identified seven actionable findings: two High and five Medium. The highest priority issues are the broad execution surface of privilege-defining database operations and service-to-service operations that rely on shared credentials without sufficiently evidenced operation-level scoping. No finding was marked closed because this phase did not authorise application or service changes.
| Severity | Open | Closed |
|---|---|---|
| High | 2 | 0 |
| Medium | 5 | 0 |
Detailed technical findings
The Security findings register expands all seven API findings with the identified technical condition, current control availability, security effect, remediation instrument, resolution sequence, and exact closure test. The register also shows the related web findings where one root cause crosses both assessment scopes.
Scope and rules of engagement
Included
- Managed Data API, approved database operations, and row-level-security boundaries.
- User-facing serverless operations, administrative workflows, scheduled operations, and external-provider callbacks.
- Session validation, service authentication, function-level authorisation, request parsing, cross-origin policy, error handling, and third-party response handling.
- Current active-function inventory and read-only managed-backend security advisories.
Excluded
- Active production requests, fuzzing, object-identifier substitution, cross-tenant access attempts, token attacks, rate-limit testing, resource-exhaustion tests, and destructive payloads.
- Provider infrastructure, Cloudflare account controls, source-code changes, secrets, and detailed endpoint or data-model disclosure.
- Full API contract verification, because a complete approved API specification and test collection are not currently available.
Dynamic production testing remains gated by written authorisation, an approved endpoint and domain inventory, permitted source addresses, test accounts, timing, data-handling rules, contacts, stop conditions, and rollback arrangements.
Methodology
- Map browser, database, serverless, scheduled, and provider-callback trust boundaries.
- Review platform-level and handler-level authentication behavior.
- Inspect object, property, function, tenant, and role authorisation patterns.
- Review input parsing, sensitive business operations, resource limits, cross-origin policy, error handling, external requests, and webhook verification.
- Compare the active managed-service inventory with the available implementation evidence.
- Use read-only security-advisor results to identify privileged database exposure.
- Classify risk using OWASP API Security Top 10:2023 and CVSS 4.0 principles. Numerical vectors are omitted where active validation was not authorised.
Findings
API-001 · Privilege-defining database operations have an over-broad execution surface
Severity: High · Status: Open · OWASP API: API5:2023 Broken Function Level Authorization
The managed security advisor reports that a broad set of elevated database operations can be invoked by ordinary application roles. Some operations intentionally centralise business rules, but they bypass normal row-level behavior unless every operation independently verifies the actor and requested scope.
Impact: A single operation with an incomplete user, tenant, role, property, or ownership check exposes or modifies records beyond the caller's authorised scope.
Required action: Revoke execution by default; grant each operation only to its required role; validate the authenticated actor, tenant, object, property, and intended transition; stabilise object resolution; and add negative cross-tenant and privilege-escalation tests.
API-002 · Elevated service operations rely on shared credentials without fully evidenced granular scoping
Severity: High · Status: Open · OWASP API: API2:2023 Broken Authentication and API5:2023 Broken Function Level Authorization
Scheduled and service-to-service operations use long-lived shared credentials before performing elevated actions. The reviewed evidence does not consistently demonstrate sender binding, per-operation credentials, rotation enforcement, request replay protection, or a second authorisation decision for every caller-controlled scope value.
Impact: Theft or unintended reuse of a shared credential provides a larger operational and data- access scope than one integration or scheduled task requires.
Required action: Use a separate credential and least-privilege identity per operation, rotate credentials, bind callers where possible, add timestamp and replay protection, restrict allowed business scope server-side, and alert on unusual source, volume, destination, or tenant patterns.
API-003 · Pre-authentication validation permits account-context discovery and lacks an evidenced abuse control
Severity: Medium · Status: Open · OWASP API: API2:2023 Broken Authentication and API6:2023 Unrestricted Access to Sensitive Business Flows
A pre-authentication validation flow returns distinguishable responses for invalid tenant context and invalid user association. No application-level attempt counter, progressive delay, or caller-specific rate control was identified in that flow. Provider-level controls were not available for verification.
Impact: Automated requests discover valid account context, support credential attacks, and create avoidable backend load when the distinguishable response is enumerated.
Required action: Return a uniform failure response, apply per-source and per-account rate limits, add progressive delay and temporary lockout thresholds, monitor repeated failures, and avoid logging submitted secrets or personal identifiers.
API-004 · Wildcard browser-origin policy is used across trusted endpoints
Severity: Medium · Status: Open · OWASP API: API8:2023 Security Misconfiguration
Multiple trusted endpoints permit requests from any browser origin. Authentication and signature verification still provide separate controls, but the policy unnecessarily expands browser reachability and increases the consequence of another control failure.
Impact: A malicious website reaches the affected endpoint from an unapproved origin. A separate authentication, credential, or response defect then exposes the action or response.
Required action: Classify endpoints as browser, provider-callback, scheduled, or internal; allowlist only approved application origins for browser endpoints; omit cross-origin headers for non-browser operations; and test preflight, credential, unauthorised, and error responses.
API-005 · Internal and provider error details can reach API callers
Severity: Medium · Status: Open · OWASP API: API8:2023 Security Misconfiguration
Several handlers return raw database, runtime, or third-party error text to the caller. Some responses include operational identifiers, provider content, constraint information, or implementation context that is unnecessary for the client.
Impact: Detailed errors help an attacker map internal behavior, identify dependencies, and refine later attacks and disclose personal or transaction context in logs and client-visible responses.
Required action: Return stable public error codes and generic messages, record detailed diagnostics only in protected monitoring, remove provider response bodies from client errors, and review logs for data minimisation and retention.
API-006 · Complete API inventory, contract, and lifecycle evidence is not available
Severity: Medium · Status: Open · OWASP API: API9:2023 Improper Inventory Management
The managed platform exposes several API styles, including generated data access, approved database operations, serverless functions, realtime channels, object storage, and provider callbacks. A single approved inventory with owners, authentication, data classification, version, consumers, and retirement state is not currently available.
Impact: Undocumented, obsolete, or differently configured interfaces escape consistent review, monitoring, testing, and controlled retirement.
Required action: Create a versioned API catalogue and machine-readable contracts where applicable; record owner, environment, authentication, authorisation, data class, rate limit, consumer, logging, and retirement date; and reconcile it automatically with the active managed-service inventory.
API-007 · Serverless runtime dependencies are not consistently immutably pinned
Severity: Medium · Status: Open · OWASP API: API8:2023 Security Misconfiguration and API10:2023 Unsafe Consumption of APIs
Serverless code imports selected runtime libraries by a broad release line rather than an immutable version. No consolidated automated vulnerability or integrity evidence was available for this runtime dependency graph.
Impact: A future upstream release changes behavior, introduces a vulnerability, or makes a rebuild non-reproducible without an intentional application change.
Required action: Pin reviewed runtime versions, use a lock or vendor mechanism where supported, scan the serverless dependency graph, review release notes before upgrades, and retain a software bill of materials with the deployed release.
Positive controls observed
- User-facing trusted operations commonly validate the managed user session before privileged processing.
- Several elevated workflows perform explicit tenant, role, hierarchy, or ownership checks in addition to authentication.
- Provider callbacks use a shared-secret or cryptographic signature where a user session is not appropriate.
- A reviewed payment callback implements signature validation and duplicate-event handling.
- Request methods and basic payload shape are validated in many handlers.
- Ordinary data access is designed to use the caller's session with row-level security, while elevated credentials are confined to trusted server execution.
OWASP API Security Top 10:2023 coverage
| Category | Coverage in this assessment |
|---|---|
| API1 Broken Object Level Authorization | Static control review; identifier-substitution and cross-tenant tests not performed |
| API2 Broken Authentication | User-session, callback, and service-credential patterns reviewed |
| API3 Broken Object Property Level Authorization | Request and update patterns reviewed; active property-manipulation tests not performed |
| API4 Unrestricted Resource Consumption | Static limit review only; load and cost-amplification tests excluded |
| API5 Broken Function Level Authorization | Administrative and privilege-defining operation review |
| API6 Unrestricted Access to Sensitive Business Flows | Pre-authentication and provider-cost flows reviewed; automation tests excluded |
| API7 Server Side Request Forgery | External-request destinations reviewed; active URL manipulation tests excluded |
| API8 Security Misconfiguration | Cross-origin, error, authentication-layer, and dependency configuration reviewed |
| API9 Improper Inventory Management | Active deployment reconciled against available evidence; complete approved contract absent |
| API10 Unsafe Consumption of APIs | Callback verification, response handling, and runtime-provider dependencies reviewed |
Remediation and retest
The assessment remains open until each finding has an owner, target date, implemented control, and verification evidence. Item 9 records remediation status only after validated fixes exist. Item 10 remains unavailable until the relevant fixes have been retested. An authorised independent assessor then performs dynamic tests for object, property, and function-level authorisation; authentication; replay; rate limits; input handling; and business-flow abuse.