What you'll receive,
redacted for the public.

1. Executive Summary

During the engagement period, TrustEdge Labs performed a Web Application Security Analysis of {{the Client's customer-facing platform}}on behalf of {{Client Name}}. Testing was scoped to the production web application, its REST and GraphQL APIs, and the authentication flows of the third-party identity provider, and was conducted under a signed engagement letter and the Rules of Engagement document attached as Appendix A.

We identified 15 findings: 1 critical, 2 high, 4 medium, 3 low, and 5 informational. The most consequential findings are summarized in §4 and detailed in §5. The combined risk picture is moderate-to-high — the critical issue (FND-001, an authenticated IDOR exposing tenant-cross document retrieval) can be remediated without architectural change in under one engineer-day.

We recommend prioritizing the four issues marked Immediate, then addressing the Within 30 days group, then incorporating the Within 90 days hardening list into a normal sprint. A re-test of the remediated findings is included in this engagement and should be booked within the post-engagement window.

2. Engagement Overview

2.1 Scope

In scope:

• Production web application at {{app.example.com}}
• REST API at {{api.example.com}} and GraphQL endpoint at /graphql
• Authentication via {{IdP}} (OIDC flow only)
• The customer support tenant-impersonation feature

Out of scope:

• The Client's marketing website ({{www.example.com}})
• Third-party SaaS integrations managed by external vendors
• Volumetric / DDoS testing
• Social-engineering of Client staff

2.2 Approach

We worked from a threat-model agreed in the kick-off session and exercised: authentication and session flows, authorization and multi-tenant isolation, business-logic abuse, injection (SQL/NoSQL/template/header), client-side XSS/CSRF/CORS/CSP, server-side request forgery and deserialization, the API surface (REST + GraphQL — schema, rate limit, mass assignment), and third-party / supply chain exposure. Every finding in this report was hand-verified — no unfiltered scanner output is included.

2.3 References

Engagement was conducted against OWASP Top 10 (2021), OWASP ASVS Level 2, OWASP WSTG, OWASP API Security Top 10, and NIST SP 800-115. These are public technical standards we work against — not certifications we hold or issue. The findings here do not, on their own, satisfy a regulator-issued audit certificate (SOC 2, ISO 27001, PCI-DSS, GDPR, HIPAA, KVKK, BDDK, TSE, etc.).

2.4 Timeline

3. Risk Picture

3.1 Severity rubric

We use a five-level severity scale aligned with industry practice:

Critical

Direct, unauthenticated path to broad compromise (data theft, RCE, account takeover at scale).

High

Significant impact, but exploitation requires specific conditions (e.g. authenticated user, victim interaction).

Medium

Real impact under realistic conditions, but limited blast radius.

Low

Real issue with very limited exploitability or impact.

Informational

Hardening guidance — not currently exploitable, but improves resilience.

3.2 Findings by severity

4. Top Findings

1. [FND-001] Authenticated IDOR — cross-tenant document retrieval — Critical. The /api/v1/documents/:id endpoint enforces authentication but not tenant isolation; any logged-in user can read any document by ID.
2. [FND-002] OAuth state parameter not validated on callback — High. Allows CSRF-style account linking on the identity-provider callback flow.
3. [FND-003] GraphQL introspection enabled in production — High. Reveals internal schema, including admin-only mutations, to unauthenticated callers.
4. [FND-004] Rate limiting bypass via X-Forwarded-For — Medium. Per-IP limits are computed from a header the upstream LB passes through unmodified.
5. [FND-005] Inadequate Content Security Policy — Medium. CSP allows 'unsafe-inline' and 'unsafe-eval', negating XSS mitigation that would otherwise apply.

5. Detailed Findings

5.1 [FND-001] Authenticated IDOR — cross-tenant document retrieval

Severity: Critical   ·   Status: Open   ·   Affected: GET /api/v1/documents/:id   ·   References: OWASP ASVS V4.2, CWE-639

Description. The document-retrieval endpoint verifies that the caller is authenticated but does not verify that the requested document belongs to the caller's tenant. Any logged-in user can substitute another tenant's document ID (a UUIDv4 — guessable only via leak, but leaked in internal Slack channels and customer support tickets in practice) and receive the full document body.

Reproduction.

1. Authenticate as a normal user in tenant A; obtain a session token.
2. Obtain the UUID of a document in tenant B — for example from a leaked Slack message or a customer support ticket.
3. Issue the request below; the response contains the full document content despite the cross-tenant boundary.

GET /api/v1/documents/c9b6e1d2-...-4f8b HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi...

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": "c9b6e1d2-...-4f8b",
  "tenant_id": "B",      ← caller is in tenant A
  "title": "Q4 board pack — DRAFT",
  "body": "..."
}

Impact. Full read access to documents of any tenant. In a SaaS that hosts board packs, financials, or legal correspondence, this is a direct breach of customer confidentiality and a notifiable data incident under GDPR Art. 33 / KVKK Art. 12.

Remediation. Add a tenant check in the document-loading service. The smallest correct fix is shown below — confirm the requested document's tenant_id matches the caller's session tenant before serializing the response. Add an integration test that asserts a 403 for cross-tenant access. Audit related endpoints (/api/v1/projects/:id, /api/v1/clients/:id) for the same pattern.

async function getDocument(id, session) {
  const doc = await db.documents.findById(id);
  if (!doc) throw notFound();
  if (doc.tenant_id !== session.tenant_id) {
    throw forbidden();   // ← was missing
  }
  return doc;
}

Verification. During re-test we will repeat the reproduction steps and confirm a 403 Forbidden response with no document body.

5.2 [FND-002] OAuth state parameter not validated on callback

Severity: High   ·   Status: Open   ·   Affected: GET /auth/callback   ·   References: OWASP ASVS V3.5, CWE-352

(Full write-up redacted in the public sample. Real reports include the same depth of detail as FND-001.)

5.3 – 5.15 Additional findings (redacted)

The remaining 13 findings — covering GraphQL introspection, rate-limit bypass, CSP weaknesses, file-upload handling, error-message disclosure, and three informational hardening items — are redacted in this public sample. Each real finding includes description, reproduction, impact, remediation, and verification steps in the same format as FND-001 above.

6. Recommendations

6.1 Immediate (this week)

• FND-001 — add tenant check to document-load path; audit related endpoints.
• FND-003 — disable GraphQL introspection in production environments.

6.2 Within 30 days

• FND-002 — validate OAuth state parameter; add CSRF token to callback handler.
• FND-004 — compute rate limits from the trusted upstream IP only.
• FND-005 — tighten CSP; remove 'unsafe-inline', move inline scripts to nonce-based or external files.

6.3 Within 90 days

• Add server-side authorization tests for every multi-tenant endpoint.
• Add CSP report-uri to catch silent regressions.
• Roll out subresource integrity for static assets loaded from CDN.

6.4 Strategic — next 6 months

• Adopt a tenant-aware data-access layer that fails closed by default.
• Add a regression test in CI that asserts cross-tenant calls return 403.
• Consider a quarterly internal review of authorization paths as net-new endpoints land.

7. Re-test

A single round of re-testing is included in this engagement, available through July 26 of the engagement year. Notify us at security@trustedgelabs.dev when remediation is ready and we will schedule the verification round. After re-test, an updated findings document with the verification results will be issued.

8. Appendices

A. Rules of Engagement

The signed RoE document is attached to the original report PDF.

B. Tooling

Burp Suite Professional, ffuf, sqlmap, OWASP ZAP, custom scripts, Postman, jq. All tooling is owned and licensed by TrustEdge Labs.

C. Contact

For questions, clarifications, or to schedule re-testing:

• Email: security@trustedgelabs.dev
• Postal: Cihan Karabalta — TrustEdge Labs, registered address on the Imprint page at trustedgelabs.dev/legal/imprint.

Confidentiality. The actual report contains information confidential to the Client. Distribution is limited to authorized recipients and to TrustEdge Labs personnel directly involved in the engagement. The findings and remediation guidance in real reports are technical in nature and do not, on their own, constitute a regulator-issued audit certificate for any compliance framework.