Home labs & practical projects

Check authorisation across two test user accounts

A project to do with your own tools, with guidance on what to create and capture.

Authorised security lab Suggested time: 2–3 hoursYour own authorised environment

What you could create

A training web application has two users and separate private records. The assessment asks whether server-side authorisation protects the records consistently.

Example evidence format

Project evidence map (example)

Application access test matrixScope and inputs

Finding report and regression specificationDecisions and reasoning

Evidence record (example)

Evidence	What to capture
Application access test matrix	Show the inputs, scope and decisions behind this record. Each result identifies the user, action and expected permission.
Finding report and regression specification	Include the evidence supporting your conclusion. Hiding a button in the interface is not treated as an authorisation fix.

What you'll need

Authorised security lab

Use an intentionally vulnerable local application with synthetic users and data. Define the permitted account and record combinations before testing.

Project record

Keep the working files for application access test matrix and record assumptions as you go.

Current reference material

Use the linked provider resources to verify the features, access terms and version relevant to your project.

Access & cost

Use a deliberately vulnerable local image or a licensed training range. Check the provider’s access terms and current price.

Only test systems you own or are explicitly authorised to assess. Keep targets isolated and use synthetic accounts and data.

Suggested milestones

1
Plan and investigate
Map application actions and their expected access rules.
2
Develop your approach
Run the training application’s permitted authorisation checks using both accounts.
3
Verify and explain
Document the boundary failure and propose server-side checks and regression coverage.

Evidence worth keeping

Keep clear, organised evidence of your design and any testing you carry out.

1
Application access test matrix
Show the inputs, scope and decisions behind this record. Each result identifies the user, action and expected permission.
2
Finding report and regression specification
Include the evidence supporting your conclusion. Hiding a button in the interface is not treated as an authorisation fix.

Label design proposals and observed results clearly.

Explain your work

Use these prompts to reflect on your decisions and what you learned.

Which part of your application access test matrix needed the most judgement?
What observation or assumption changed your approach?
What would you improve, and what have you not verified?

Describe this as a personal project in your portfolio.

Useful resources

Use these resources to deepen your understanding and check key details.

Official certification objectives

Review the current provider requirements and relevant subject areas.

Explore external learning resources

Find relevant providers and check features, access requirements and costs.

A useful starting point

Use an intentionally vulnerable local application with synthetic users and data. Define the permitted account and record combinations before testing.

What a good result looks like

Each result identifies the user, action and expected permission.
Hiding a button in the interface is not treated as an authorisation fix.

Finish the project

Revert target snapshots, remove test accounts and artefacts, and store a sanitised report. Do not publish credentials or working attack material.

Independent home-project guidance, not an official vendor lab or a claim of complete exam coverage. Use your own tools and label the work accurately.