Web & Mobile Application Security case study

Web and API Vulnerability Validation Lab

Validated OWASP-aligned weaknesses in a local crAPI environment, preserving request/response evidence across authorization, authentication, rate limiting, injection, and security configuration.

Skills demonstrated

  • Mapped reachable directories and application technologies.
  • Tested object ownership and order-ID authorization boundaries.
  • Evaluated JWT signature enforcement and login throttling.
  • Exercised SQL and NoSQL inputs and inspected excessive response data.
  • Documented exposed configuration, OTPs, PII, and deprecated API inventory.

Tools used

  • Burp Suite
  • Gobuster
  • Wappalyzer
  • JWT tooling
  • Docker
  • manual API testing

Technical walkthrough

Lab evidence and investigation steps.

Open on GitHub
Ref 1: Using gobuster to enumerate target 127.0.0.1:9000 the directory with http code 200k are part of the domain. Example: 127.0.0.1:9000/health.
Ref 1: Using gobuster to enumerate target 127.0.0.1:9000 the directory with http code 200k are part of the domain. Example: 127.0.0.1:9000/health.
Ref 2: Wappalyzer shows the technologies used to build the crAPI web application.
Ref 2: Wappalyzer shows the technologies used to build the crAPI web application.
Ref 3: Vulnerabilities: By changing the user id value from 8 to 3. I am able to access other users data.
Ref 3: Vulnerabilities: By changing the user id value from 8 to 3. I am able to access other users data.
Ref 4: After login a JWT token is provided by the server.
Ref 4: After login a JWT token is provided by the server.
Ref 5: After login a JWT token is provided by the server.
Ref 5: After login a JWT token is provided by the server.
Ref 6: the encryption is changed to none and the signature is removed.
Ref 6: the encryption is changed to none and the signature is removed.
Ref 7: The server responds to the modified JWT token. Vulnerabilities: The server does not verify the JWT tokens therefore when the token is modified the server does not detect this action.
Ref 7: The server responds to the modified JWT token. Vulnerabilities: The server does not verify the JWT tokens therefore when the token is modified the server does not detect this action.
Ref 8: bruteforcing the password field using a wordlist and burpsuite intruder
Ref 8: bruteforcing the password field using a wordlist and burpsuite intruder
Ref 9: The server responds to 50 wrong passwords without account lock out. vulnerabilities:
Ref 9: The server responds to 50 wrong passwords without account lock out. vulnerabilities:
Ref 10: Vulnerabilities:
Ref 10: Vulnerabilities:
Ref 11: The api endpoint /community/api/v2/community/posts is vulnerable to sql injections.
Ref 11: The api endpoint /community/api/v2/community/posts is vulnerable to sql injections.
Ref 12: The sql payload on the ‘content’ field responds with same payload input from user which means there is no input sanitization.
Ref 12: The sql payload on the ‘content’ field responds with same payload input from user which means there is no input sanitization.
Ref 13: NO SQL INJECTION
Ref 13: NO SQL INJECTION
Ref 14: vulnerability:
Ref 14: vulnerability:
Ref 15: When the password field is fuzzed using sql payloads, the server returns a message that has excessive information disclosure
Ref 15: When the password field is fuzzed using sql payloads, the server returns a message that has excessive information disclosure
Ref 16: http://127.0.0.1:8888/.env exposes the database configuration.
Ref 16: http://127.0.0.1:8888/.env exposes the database configuration.
Ref 17: vulnerabilities:
Ref 17: vulnerabilities:
Ref 18: 4
Ref 18: 4
Ref 19: vulnerabilities
Ref 19: vulnerabilities
Ref 20: Vulnerability:
Ref 20: Vulnerability: