Safety Center
Security Research for Beginners: Start Safely
Security research means finding, understanding and explaining weaknesses in systems — so they can be fixed. This guide shows beginners how to start, legally and safely, in labs and authorised programmes only.
What security research actually is
Security research is the disciplined study of how systems break. A researcher picks a piece of software or a system, learns how it is supposed to work, looks for places where it does not — an input that is trusted when it should not be, a check that can be bypassed, a secret that is exposed — and then explains the weakness clearly enough that someone else can reproduce it and fix it. The best single description found in the research for this site puts it plainly: research is 'finding, understanding and explaining weaknesses'.
That third word — explaining — is where most beginners underestimate the work. A weakness you cannot explain is not a finding; it is a hunch. Professional researchers spend as much time writing, verifying and communicating as they do testing, and the write-up is what turns a discovery into a fix.
The permission rule, stated once and for all
Permission first, always. Only research systems you own, systems in a legal lab, or systems covered by a public programme that invites testing within a defined scope. Never scan, probe or test a live system without written permission. Reporting a bug afterwards does not make an unauthorised test legal.
This rule is not a formality. Computer-misuse laws in many countries make unauthorised access an offence regardless of motive, and the research community's norm — coordinated vulnerability disclosure — exists precisely to keep good-faith researchers on the right side of that line: report privately first, give the owner time to fix (a window of around 90 days is commonly cited, though it varies by programme), and only disclose publicly after a fix or after the agreed window, and never publish a working exploit before a fix.
Where you may look
There are four safe places to research. First, your own lab: virtual machines and intentionally vulnerable applications you install yourself, where you may break anything. Second, free legal learning labs: PortSwigger Web Security Academy for web weaknesses, Hacker101 for guided practice, and hands-on platforms such as TryHackMe and HackTheBox. Third, open-source software: reading code, finding weaknesses in public code, and reporting them through the project's own disclosure process. Fourth, public vulnerability disclosure programmes and bug bounties, within their published scope — see our bug bounty guide and scope-reading guide.
Notice what is not on the list: live websites you happen to use, your employer's systems without written approval, public infrastructure, and anything you found by scanning the internet. If it is not yours, not a lab, and not in a programme scope, it is not a research target.
The research loop
- Learn the system. Read the documentation. Understand what it is supposed to do before you look for what it does wrong.
- Form a hypothesis. 'This input reaches that function without a check' is a hypothesis; 'this site is insecure' is not.
- Test in the lab. Reproduce the behaviour in a controlled environment, with notes at every step.
- Determine impact honestly. A crash is not a vulnerability by itself. What can an attacker actually do with this — read data they should not see, act as another user, change something they should not change? If the answer is 'nothing meaningful', it is not a finding.
- Write it up. Use the structure in our vulnerability report template: what, where, how to reproduce, evidence, impact, suggested fix.
- Disclose responsibly. Privately, through the right channel, with a reasonable window for a fix.
Core knowledge for beginners
- How the web works: HTTP, cookies, sessions, authentication — the substrate of most beginner research.
- Common weakness classes: injection, broken access control, misconfiguration, and information disclosure, as concepts first and techniques second. The OWASP Top 10 is the standard vocabulary.
- Reading code: even basic code-reading ability multiplies what you can find. You do not need to be a developer; you need to follow data through a function.
- CVE, CVSS and KEV: how vulnerabilities are named, scored and prioritised — explained in our CVE guide.
- MITRE ATT&CK: the shared map of attacker techniques, explained in our ATT&CK guide.
Reading disclosed reports: the fastest teacher
Before you search for your first weakness, spend two weeks reading disclosed vulnerability reports. Study what a good report looks like: a precise title, reproduction steps a stranger can follow, evidence, and an honest impact statement. Study rejected reports too — duplicate, out of scope, or 'not a vulnerability' — because they teach the judgement that separates researchers from people who file noise. The research guides consistently recommend this step, and the researchers who skip it are the ones whose first reports get closed as uninformative.
From research to a career
Security research feeds directly into four careers: vulnerability research itself, bug bounty hunting, penetration testing, and threat intelligence. Each values the same core skills — method, evidence, writing, and discipline about permission. Keep a portfolio of your lab write-ups and responsible disclosures (sanitised, with no exploit code aimed at live targets) and it will speak for you in applications. The portfolio rules are in our portfolio guide, and the career map in cybersecurity careers.
Learning to read code
You do not need to be a software developer to research software, but basic code reading multiplies what you can find. Start with small, readable open-source projects in a language you are learning, and practise following data through a function: where does this input come from, where does it go, what checks does it pass? The skill is tracing, not writing. The exercise that teaches it fastest is to take a disclosed vulnerability in an open-source project, read the fix commit, and then read the vulnerable version to see exactly what the fix changed. That loop — vulnerable code, fix, vulnerable code again — teaches you to see the weakness the way the researcher saw it.
Common beginner mistakes
- Testing a live system 'just to check'. The most serious mistake. The test itself is the act that needs permission, and there is no exception for curiosity.
- Confusing a crash with a vulnerability. A crash is interesting only if it shows an attacker can do something meaningful — read data, act as another user, change state. Report impact, not crashes.
- Skipping the write-up. A finding you cannot explain to a stranger is not yet a finding. Write it up, and the gaps in your understanding will reveal themselves.
- Copying other people's reports. Triage teams recognise copied write-ups, and so do hiring managers. Original work, even if modest, is worth more than impressive copied work.
- Chasing advanced techniques before fundamentals. The researchers who find the most are usually the ones with the deepest grasp of the basics — how the system works, not which tool is newest.
Sources
- Security Research, Explained — blogs.g0w6y.com (what research is, CVE/CNA, disclosure timelines, safe starting points)
- NCC Group — Breaking Into Security Research (professional-firm view)
- CERT Guide to Coordinated Vulnerability Disclosure
- Research methodology — how this guide was researched
Frequently asked questions
What is security research?
Security research is the study of how systems can fail or be misused: finding weaknesses, understanding how they work, and explaining them clearly so they can be fixed. It is the foundation of vulnerability disclosure, bug bounties and threat intelligence.
How do I start security research with no experience?
Start with foundations (how the web and networks work), practise in free legal labs, read disclosed vulnerability reports, and learn to write clear findings. Never practise on live systems you do not own or have permission to test.
Is security research legal?
Research in your own lab or in authorised programmes is legal. Testing, scanning or probing a live system without the owner's written permission is unlawful in many countries, even with good intentions. Permission decides legality.
Where can I practise security research legally?
Free legal labs such as PortSwigger Web Security Academy and Hacker101, hands-on platforms such as TryHackMe and HackTheBox, and public vulnerability disclosure programmes that invite reports within a defined scope.
What is the difference between security research and hacking?
Security research is done with permission, in labs or authorised programmes, and ends in a responsible report. Unauthorised access — however well-intentioned — is hacking in the legal sense, and reporting afterwards does not make it lawful.
How long before I can find a real vulnerability?
There is no fixed timeline. Beginners who study fundamentals, practise in labs, and read disclosed reports typically file their first valid report through a disclosure programme after several months of steady work. Treat it as a skill built over months, not days.