API security assessment laboratory
A controlled laboratory for testing API authentication, authorisation, input handling, rate limits, and security monitoring against documented test cases.
Project definition
Problem statement
API security failures often depend on user roles, object ownership, request order, token state, and business rules. A generic scanner cannot reliably test these conditions without a controlled model of the API.
The engineering problem is to build a safe laboratory that defines expected security behaviour, executes repeatable authorised tests, records evidence, and verifies whether a remediation closes the original weakness.
Project objectives
- Create an isolated API with documented roles, objects, workflows, and security controls.
- Test authentication, object and function authorisation, input validation, resource limits, and security headers.
- Record requests, responses, expected behaviour, actual behaviour, and reproducible evidence.
- Classify findings by impact, likelihood, affected control, and remediation status.
- Measure test coverage and confirm fixes by rerunning the same cases.
System design
System modules
Target API
Provides prepared secure and intentionally flawed endpoints inside an isolated Docker network.
Test-case builder
Defines identities, preconditions, request sequences, assertions, cleanup, and safety limits.
Assessment runner
Executes approved cases, manages tokens, captures responses, and prevents requests outside the lab allowlist.
Finding manager
Links failed assertions to evidence, affected endpoints, severity reasoning, and remediation guidance.
Coverage dashboard
Shows tested controls, endpoint and role coverage, open findings, retest results, and exported summaries.
Methodology
System workflow
- 01Load lab scenario
The student starts the isolated API and imports its endpoint, role, and expected-control definitions.
- 02Define tests
Cases are prepared for valid and invalid access, malformed input, workflow misuse, and resource limits.
- 03Run assessment
The runner executes only allowlisted requests and records assertions and evidence.
- 04Apply remediation
A documented control change is enabled for a confirmed finding.
- 05Retest and compare
The same case is rerun and the dashboard compares behaviour and coverage before and after the change.
Demonstration scenario
A student runs an object-authorisation test using two seeded accounts. The lab records that one user can read another user’s object, creates a finding with request evidence, enables the ownership check, and reruns the same case to show that the unauthorised request is rejected.
Engineering
Technical architecture
- Web application
- Nuxt and Vue for scenario selection, case review, finding evidence, coverage, and retest comparison.
- Assessment API
- FastAPI for test orchestration, assertions, evidence, findings, and report export.
- Data layer
- PostgreSQL for scenarios, endpoints, roles, test runs, evidence, findings, and remediation history.
- Security tooling
- Python request tooling with optional OWASP ZAP integration for passive checks inside the isolated environment.
- Isolation
- Docker networks, target allowlists, request limits, seeded accounts, and resettable lab data.
Testing
Evaluation
Evaluation measures
- Detection rate across prepared vulnerable and secure cases
- False-positive rate against documented expected behaviour
- Endpoint, method, role, and control coverage
- Evidence completeness and test reproducibility
- Successful verification of prepared remediations
- Execution time and enforcement of lab safety limits
System boundaries
- Testing is limited to the included local target and systems for which explicit authorisation has been granted.
- The runner blocks targets outside its configured lab allowlist.
- The project demonstrates assessment methods and does not guarantee that an API is secure.
- No destructive, denial-of-service, credential theft, or persistence testing is included.
Included
- 01Isolated target API and assessment dashboard
- 02Repeatable test-case runner and evidence recorder
- 03Finding classification and remediation comparison tools
- 04Prepared API scenarios, tests, and coverage results
- 05Complete source code in a private GitHub repository
- 06Complete project documentation with synopsis, abstract, methodology, security diagrams, test results, screenshots, and conclusion
- 07Setup and usage guide
Project record
No buyer information is collected on this page.
- Permanent project ID
- GP-CY-11PBZ9X
- Catalogued
- 21 Aug 2026
- Completed
- Pending
- Verified
- Pending
- Demonstration
- Added when ready
Handover
After purchase
- 01Payment is confirmed
The project is marked unavailable and cannot be purchased again.
- 02Repository access is granted
The buyer's submitted GitHub account receives access to the private repository.
- 03The purchase record is delivered
The certification sheet is prepared from the reviewed buyer details and sent privately by email.