Samuel K. Addison

Reflections from a Recent Web Application Security Assessment

During a recent black‑box engagement on a SaaS platform that manages cyber‑attack permission requests, our team uncovered a cascade of classic yet still‑dangerous web‑application flaws. From directory‑traversal that leaked system files to a mis‑configured JWT implementation that allowed token replay, the findings illustrate how easy it is for an attacker to pivot from low‑level bugs to full‑scale compromise. Below we walk through the most critical issues, why they matter, and how developers can remediate them—while keeping the client’s confidential details private.

Why a Structured Assessment Matters

Aligning a penetration test with the OWASP Top 10 and the ASVS gives a repeatable checklist, ensures coverage of the most common attack vectors, and helps prioritize remediation based on risk.

Top 5 High‑Impact Findings

1. Directory Traversal

An endpoint that served static files allowed path manipulation (../) resulting in the exposure of files outside the web root, such as system configuration files. This demonstrates how a seemingly harmless file‑serving route can become an information‑leak vector.

2. Improper JWT Handling

The application used a weak signing secret and did not enforce short token lifetimes. An attacker could crack the secret, forge tokens, and extend sessions indefinitely, effectively bypassing authentication.

3. Mass‑Assignment in Role Creation

The registration endpoint accepted arbitrary JSON fields. By adding a "role":"admin" attribute, a regular user could self‑assign administrative privileges, breaking the principle of least privilege.

4. Insecure Direct Object Reference (IDOR)

Authenticated users could modify any application record simply by guessing its identifier. No ownership check was performed on the PUT /applications/{id} endpoint, allowing unauthorized edits.

5. NoSQL Injection

The user‑lookup endpoint concatenated the supplied identifier directly into a MongoDB query. By injecting a crafted payload, an attacker retrieved the entire user collection, exposing emails, roles, and other personal data.

Other Noteworthy Issues

  • Verbose error messages that leaked stack traces.
  • CORS policy set to *, allowing any origin to make authenticated requests.
  • No rate‑limiting or CAPTCHA on login – enabling brute‑force attacks.
  • Open redirect in the “Target Website” field of the application‑creation form.
  • Potential SSRF leading to delayed responses and possible denial‑of‑service.

Remediation Blueprint

Directory Traversal

  • Never concatenate user input with file paths. Use a safe‑join library or whitelist allowed filenames.
  • Serve static assets from a dedicated folder with path.resolve() checks.

JWT Handling

  • Generate a strong, random secret (≥256 bits) and rotate it regularly.
  • Set short exp claims (e.g., 15 min) and implement refresh‑token revocation.
  • Validate the token’s audience and issuer fields.

Mass‑Assignment

  • Implement server‑side DTO validation and whitelist only the fields that may be set by the client.
  • Reject any unexpected properties with a 400 response.

IDOR

  • Verify ownership before performing any update/delete operation.
  • Consider using opaque identifiers (UUIDs) that are not guessable.

NoSQL Injection

  • Never embed raw user input into query objects. Use parameterized queries or an ORM that enforces schema validation.
  • Sanitize and type‑check all incoming identifiers.

Additional Fixes

  • Return generic error messages; log detailed stacks internally only.
  • Restrict CORS to known origins (e.g., https://app.example.com).
  • Apply exponential back‑off, CAPTCHAs, or account lockout after repeated failed logins.
  • Validate redirect URLs against an allow‑list or enforce same‑origin redirects.
  • Whitelist outbound hosts for any user‑supplied URLs to mitigate SSRF.

Lessons Learned

The assessment reinforced three universal truths:

  1. Defaults are dangerous. Open CORS, permissive error handling, and unchecked fields are common starter kits for attackers.
  2. Validation must be server‑side. Client‑side checks are nice for UX, but they never replace robust back‑end enforcement.
  3. Continuous testing pays off. Even a brand‑new codebase can inherit decades‑old classes of bugs if security isn’t baked in from day one.

Quick Remediation Checklist

  • ✅ Validate & sanitize all user‑controlled paths.
  • ✅ Rotate JWT secrets regularly; enforce short expiry & revocation.
  • ✅ Whitelist allowed fields on every API endpoint (prevent mass‑assignment).
  • ✅ Enforce ownership checks for every mutable resource (protect against IDOR).
  • ✅ Parameterize NoSQL queries or apply strict schema validation.
  • ✅ Hide internal error stacks; return generic error messages.
  • ✅ Restrict CORS to known origins; implement rate‑limiting on auth endpoints.
  • ✅ Sanitize all output to prevent reflected XSS.
  • ✅ Validate redirect URLs; disallow open redirects.
  • ✅ Guard against SSRF by whitelisting outbound destinations.

Further Reading / Resources

Conclusion

By addressing these findings, the platform moved from a state where an attacker could enumerate users, hijack sessions, and tamper with critical data to a far more resilient architecture. The same principles apply to any modern web application: start with a solid security framework, validate everything, and continuously test.

Stay secure!