Career path
Application / Product Security
What people in this area work on
Much of what people rely on every day is software, and many attacks target weaknesses in how it was built. Application security (often shortened to AppSec) and product security teams help developers prevent those weaknesses instead of patching them after release.
The work includes threat modeling new features, reviewing code, running automated security tests, and helping teams understand and fix what those tests find.
It suits people who like understanding how software works and enjoy working alongside developers to make practical improvements.
Terms used on this page
- Threat model
- A structured look at how a feature or system could be misused and what would prevent it.
- Authentication
- Checking who someone is, for example with a password.
- Authorization
- Checking whether a signed-in user is allowed to perform a specific action on a specific piece of data.
- Broken access control
- A weakness where users can reach data or actions they should not, such as another person’s records.
- Regression test
- An automated test that makes sure a fixed problem does not quietly come back.
How the work flows
One piece of work, start to finish. Every step below is something you can practise in the starter project.
- DesignAsk how a feature could be misused
- ReviewRead the code and the checks
- TestTry the abuse case for real
- FixCorrect it on the server side
- RegressAdd a test so it stays fixed
Examples of everyday tasks
- Review designs for new features and list the ways they could be abused.
- Read code changes for security problems.
- Run and tune automated security scanning in the tools developers already use.
- Help developers reproduce and fix vulnerabilities.
- Write secure coding guidance with concrete examples.
Related job titles
- Application security engineer
- Product security engineer
These are career areas to explore, not a checklist. Some of these job titles usually require experience, and completing a starter project does not by itself make someone ready for them.
Starter project
Protect Private Records in a Small App
Create a simple demo with two users. Test whether either user can access the other’s private records, correct the access-control weakness, and verify the fix.
This is a practice lab you build yourself with made-up users and data.
What you’ll use
- A small web app you write yourself in any language or framework you are learning
- Two made-up test users, each with a few sample records
- A way to send requests, such as a browser, a command-line tool, or an automated test
Resources to start with
- OWASP Authorization Cheat Sheet (opens in a new tab)
Practical guidance on checking permissions correctly in applications.
- OWASP Insecure Direct Object Reference Prevention Cheat Sheet (opens in a new tab)
Explains the exact weakness this project looks for: reaching records by changing an ID.
More projects for this path
Each one comes with the framework to follow, five name ideas and a walkthrough for publishing it on GitHub.
- Broken Access Control Fix
Build a two-user app, break its record access, fix it and keep it fixed.
- Secure Code Review Pack
Review a small open-source project and write findings a maintainer could act on.
- CI Security Gate
Add dependency, secret and static checks to a pipeline without blocking the team.
Project walkthrough
- Build a minimal app where each user has private records, such as notes, stored with the owner’s ID.
- Write the security requirement in one sentence, for example: a user can only view and change their own records.
- Sign in as the first user and note how a record is requested, such as a web address that contains the record’s ID.
- As the second user, request the first user’s record directly. If it loads, you have found broken access control.
- Fix the weakness by checking the record’s owner on the server for every read and every change.
- Repeat the same requests and confirm they are now refused, while each user can still reach their own records.
What to publish
- The code, in a public repository that contains sample data only
- A short explanation of the security requirement
- Before-and-after tests showing the weakness and the fix
Optional extension
Add automated regression tests so the weakness is caught if it is reintroduced.
Example résumé bullet
Numbers are what make a bullet worth reading, so count them while you work: how much data you searched, how many findings you fixed, how many tests you added. Every figure should be one a reader can find in your report. Write the line after the work is done, and leave out impact or experience you cannot show.
Numbers to record while you work
| Count | Where it comes from |
|---|---|
| Endpoints reviewed | list of routes you checked |
| Abuse cases tested | your test matrix |
| Access-control bugs fixed | before-and-after requests |
| Regression tests added | the test file in your repository |
Project name | tools, datasets and frameworks | link
KeyringNode.js, Express, OWASP ASVS, OWASP Top 10, Playwright, GitHub ActionsGitHub
Built a two-user demo application and tested 6 record endpoints for ownership checks; fixed the 2 that exposed another user’s private records and added 4 regression tests that fail if the weakness returns.
Give the project a name of its own: “Keyring” is an example, not a label to copy. List the tools, datasets and frameworks you actually used, since several relevant ones show more than a single tool does. Hyperlink the last part to your published repository or report.
A day on the job
Try the work before you try the project
A short walkthrough of a realistic situation. Nothing is scored: each choice explains what would happen, so you can talk through the reasoning later.
Can you look at this before we ship Friday?
A new feature lets members download their own receipts. It works. Sam wants a quick security opinion before release.
What do you look at first?
Changing the receipt number in the address returns someone else's receipt. How do you raise it?
Choose above to continue.
Sam pushes a fix. What do you do before it ships?
Choose above to continue.
Turn your project into a portfolio piece
A project becomes easier to evaluate when someone can understand what you did, inspect the evidence, and follow your reasoning.
Create a short report, GitHub README, or portfolio page. A clear two-to-four-page report is a useful starting point, not a strict requirement.
Include:
- Goal: What question or problem did you investigate?
- Environment: What tools, practice data, or systems did you use?
- Your work: What did you personally do, and why?
- Evidence: Include useful screenshots, queries, code, or test results.
- Findings: What did you discover? What remains uncertain?
- Fix or recommendation: What should change, and did you test it?
- Sources and limitations: Credit datasets and guides. Clearly identify simulated work.
Use sample or redacted information in the public version.
Publish the report somewhere accessible without requesting permission, and check the link before putting it on a résumé.
Put numbers in it
Count as you work, and put the figures in the report: records searched, findings confirmed, tests added, checks failing before and after. A reviewer can check every one of them against your evidence, which is exactly why they are worth including. Leave out business impact you cannot show.
Name it, then show your tools
A résumé line works best in three parts: your project’s own name, the tools and frameworks you used, and a link to the work. “Role-Based Access Lab” reads like a class exercise. A name plus a tool list tells a reviewer what you can actually work with, and every tool, dataset or framework you list honestly is another thing an interviewer can ask you about.
Project name | tools, datasets and frameworks | link
- Role-Based Access LabTurnstile | Keycloak, RBAC design, NIST SP 800-63, Docker | GitHub
- Login HuntBeacon | Python, pandas, Sigma, MITRE ATT&CK | GitHub
- Cloud ProjectBedrock | Terraform, Checkov, AWS IAM, CIS Benchmarks | GitHub
Why link a report?
Your résumé gives a short description of the project. The linked report lets a reviewer inspect your work and gives you concrete evidence and decisions to discuss during an interview.
Not every recruiter will open it, but it makes your work available for review.
BeaconPython, pandas, Sigma, MITRE ATT&CK, LANL authentication datasetGitHub
Investigated a public authentication-log dataset for repeated failed logins followed by successful access; documented search queries, supporting evidence, and limitations in a reproducible hunt report.
Hyperlink the last part to the published work, so “GitHub” or “Project Report” opens your repository or report. Check the link before you send the résumé.
Preview the write-up template
# Project title > Practice project. Describe the simulated scenario, practice data, or lab used. ## Goal What question or problem did you investigate? ## Environment What tools, practice data, or systems did you use? Link datasets and guides. ## My work What did you personally do, and why? ## Evidence Screenshots, queries, code, or test results. Use sample or redacted information only. ## Findings What did you discover? The numbers behind it (records searched, findings confirmed, tests added). What remains uncertain? ## Fix or recommendation What should change, and did you test it? ## Sources and limitations - Datasets and guides used: - What was simulated: - Limitations: