BugBounty Methodology
Recon / Web Hacking
Tags: #recon #webhacking
Links
How websites work with HTML, CSS and JavaScript
(Use the sandboxes above to quickly test HTML/JS payloads and behavior.)
Don't overcomplicate things
Logging in
Commenting on a post
Questioning (when investigating)
What did they consider when setting this up?
Can I maybe find a vulnerability here?
Can you comment with basic HTML such as
<h2>— where is it reflected on the page?Can I input XSS in my name?
Does it make any requests to an /api/endpoint which may contain more interesting endpoints?
Can I edit this post? Maybe there's IDOR?!
Developer experience
Try to understand what a payload is trying to achieve: why/how it was created, what it does, and why it was needed.
Combine payload understanding with experimenting with basic HTML and tracing the code path (POST vs GET, JSON bodies, etc).
Brute force common parameter names — you can get lucky.
Be curious and try things — you can't be wrong.
Real-life example / Vulnerability Disclosure program
Google for companies ready to work with researchers:
“responsible disclosure program”
“vulnerability disclosure program”
“vulnerability program rewards”
inurl: vulnerability disclosure
inurl: responsible disclosure
My basic toolkit
Use the stepper below for a quick overview of core tooling and commands.
ParamScanner & JS URL discovery
Custom tools that scrape endpoints and search for input names/IDs and JS variables like var{name} = "".
Links:
Javascript file scraping gist: https://gist.github.com/mhmdiaa
LinkFinder: https://github.com/GerbenJavado/LinkFinder
parameth (parameter brute forcing): https://github.com/maK-/parameth
Note: my tool trend is to find new content, parameters, and functionality to poke at.
Common issues I start with & why
Stick to what you know to create impact.
Developers repeat mistakes; find and exploit common patterns.
Look through design, frameworks in use, filters in place, and aim to bypass them.
1. Cross-Site Scripting (XSS)
Tags: #xss
One of the most common vulnerabilities on bug bounty programs.
Inject HTML into a parameter/field that gets reflected and rendered as HTML.
Example: Search form -> Enter
<img src=x onerror=alert(0)>and an alert appears.
Test every parameter; look for reflected, stored, and blind XSS.
Bypassing WAFs is iterative and often a trial-and-error process.
Awesome-WAF: https://github.com/0xInfection/Awesome-WAF
Filters can reveal developer assumptions and possible bypasses.
Create a lead when you find potential XSS.
Process for testing for XSS & filtering (stepper)
Testing encodings and behavior
Find what payloads are allowed and how the website reflects/handles them:
Try
<h2>, <img>, <table>and see if they're reflected as HTML.Check if characters are encoded (e.g.,
<vs%3cvs double-encoded%253C).
Try many encodings (see ghettoBypass): https://d3adend.org/xss/ghettoBypass
Example:
<script>reflected as<script>but%26itscript%26gtbecomes<script>— indicates a possible bypass.
Reverse-engineering developer filters
Get into the developer's head: what filters are in place and why? Where else in the app are they applied?
Examples to consider:
Are they blacklisting
<script>,<iframe>,onerror=but miss<svg>or<scriptsrc=...?Are they only matching complete HTML tags? Are encodings like
<00iframe>oron%0derrorhandled?
Keep testing different combinations and encodings.
More payloads: https://zseano.com/
Testing XSS flows
How do non-malicious tags like
<h2>behave?What about incomplete tags:
<iframe src=//hamcodes.com/c=?Test encodings:
%0d,%0a,%09,%00, etc.Try case and syntax variations:
</script/x>,<ScRipt>, etc.This process helps determine the filtering and whether a parameter is likely vulnerable.
Helpful resource: Filter bypass cheat sheet — https://github.com/masatokinugawa/filterbypass/wiki/Browser's-XSS-Filter-Bypass-Cheat-Sheet
2. Cross-Site Request Forgery (CSRF)
Tags: #csrf
Forcing a user to perform an action on the target site via a crafted request (e.g., an HTML form POST).
Example impact: force-change account email to attacker-controlled address => potential account takeover.
Developers can protect CSRF easily, but custom implementations can introduce flaws.
Testing tips and questions:
Look at sensitive areas (account update, password change, checkout).
What happens with a blank or malformed CSRF token? Does an error reveal framework info?
Are protections consistent across features (mobile vs web, different endpoints)?
Some servers only check the Referer header; creative methods can bypass Referer checks (e.g., meta referrer, data URIs, domain variations).
If you find custom CSRF defenses, look for bypasses — where there is a filter, there may be a bypass.
3. Open URL Redirects
Favorite bug often with high success because many developers implement naive redirects.
Example: https://www.google.com/redirect?goto=https://www.bing.com/ — if goto is unfiltered, it redirects anywhere.
Useful payload patterns to probe filter behavior (try variants and encodings exactly as listed — keep the payloads intact while testing):
\/yoururl.com,\/\/yoururl.com,\\yoururl.com,//yoururl.com,//theirsite@yoursite.com,/\/yoursite.com,https://yoursite.com%3F.theirsite.com/,https//yoursite.com%2523.theirsite.com/,https://theirsite.computer/,https://theirsite.com.mysite.com,/%0D/yoursite.com,/%2F/yoururl.com,/%5Cyoururl.com,//google%E3%80%82com, etc.
Common parameter names to dork for:
return,return_url,rUrl,cancelUrl,url,redirect,goto,returnTo,returnUrl,history,redirectTo,redirectUrl,redirUrl, etc.Open redirects can be chained into OAuth flows to leak tokens — watch for login flows with redirect parameters.
Encoding and double-encoding tricks help with multi-step redirects and parameter preservation.
Open redirects may also enable SSRF or XSS depending on how the redirect is executed (Location header vs window.location vs javascript:).
Example bypass tricks (encoded obfuscation):
java%0d%0ascript%0d%0a:alert(0)j%0d%0aava%0d%0aas%0d%0acrip%0d%0at%0d%0a:confirm\0``java%09scrip%07t:prompt\0``Repeating or inserting junk characters in "javascript" (various mutations) to bypass simple filters.
OAuth reference: https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2.
Server-Side Request Forgery (SSRF)
Tags: #SSRF
In-scope domain issues a request to a URL you control or specify.
Look for features accepting a URL parameter: API consoles, webhooks, developer tools.
Test how redirects are handled by the server — host redirects locally (e.g., XAMPP + ngrok) to observe behavior and timing.
Try timing attacks (add sleep in the redirect target) to detect server-side fetches.
Check whether the application follows redirects and if internal resources can be read.
Look for third-party software (Jira, Confluence, etc.) and known CVEs — these may expose server features.
Stay up-to-date with CVEs and check if filters are only superficial.
File uploads (stored XSS & RCE)
Tags: #xss
Developers often filter allowed file types incorrectly.
Files stored on the domain can allow stored XSS or remote code execution.
Test uploading atypical but plausible files:
.txt,.svg,.xml— sometimes forgotten by filters.Test file name tricks and encoding to smuggle content or change perceived extension:
hamcodes.php/.jpghamcodes.html%0d%0a.jpg(newline characters can result in saved.html)
Filenames can be reflected on pages; characters like
<svg onload=...>embedded in filenames may render.Test content-type vs extension handling: server may trust extension or content-type inconsistently.
Example payload (multipart form filename containing SVG):
Other malformed examples to test how the server treats content-type and filename:
Another example showing an image filter bypass:
Spend time testing file upload filters — it’s often fruitful.
Insecure Direct Object Reference (IDOR)
Tags: #IDOR
Example:
http://api.hamcodes.com/user/1returns user 1. Changing ID to 2 should be blocked; if not, it's IDOR.IDOR is about changing identifiers (integers, GUIDs, etc.) and observing access control failures.
GUID brute force is usually impractical; instead, look for leaks where the ID appears elsewhere (images, URLs).
Example path leak:
/images/users/2b7498e3-9634-4667-b9ce-a8e81428641e/photo.pngQuestions:
Is the value leaked anywhere? Indexed by Google?
Search for keywords like "appointment", "appointmentID".
Check mobile apps — APIs used in mobile apps are often fruitful for IDOR.
Try injecting
idfields into JSON payloads or adding parameters; check PUT requests and other verbs.
CORS (Cross-Origin Resource Sharing)
Tags: #cors
Check for
Access-Control-Allow-OriginandAccess-Control-Allow-Credentials: true.If
Access-Control-Allow-Originechoes or allows attacker-controlled origins, an external site could read sensitive responses.Access-Control-Allow-Credentials: trueis required if cookies or credentials are involved.Where filters exist, seek bypasses (e.g., slightly modified origin values).
Grep for
Access-Control-Allow-Originin responses after setting variousOriginheaders.
SQL Injection
Tags: #SQL
More common in legacy code and old features.
Test places that query the database with user input.
Error messages may be suppressed; use blind SQL techniques such as time-based payloads:
or sleep(15) and 1=1#or sleep(15)#union select sleep(15),null#
Use 15–30s delays to detect blind SQL execution.
Apply similar systematic testing across the application.
Business / Application Logic bugs
Understand how the application is intended to work and abuse logic to cause unexpected outcomes (price manipulation, privilege escalation, bypassing payment checks).
Look for interactions between new features and legacy flows.
Example: sign up with special email addresses (company domains) that may grant different privileges.
Logic bugs require understanding intended flows and identifying places to deviate.
Choosing a program (Seven-step methodology)
Spend months on a program; big companies take longer to find issues.
Choose broad scope and well-known names (more surface area).
Focus on platforms you know and expand attack surface by scanning subdomains, files, and directories.
Spend time getting into developers' heads; build a comprehensive mind-map of the company and how components interact.
Don't rush — trust the process.
Checklist for a well-run bug bounty program
Direct communication or reliance on platform (if managed service, proceed cautiously).
Active program — when was scope last updated?
How does the team handle low-hanging bugs that can be chained?
Do they reward higher-impact findings appropriately?
Response time across 3–5 reports should ideally not exceed a month.
Don't be afraid to walk away from bad experiences.
Writing notes as you hack
Save notes to avoid burnout and to keep a clear record of findings.
Track:
Interesting endpoints
Behaviors and parameters
Features that can/can't be exploited
What you've tried and what you believe is vulnerable
Notes help create custom wordlists (domain-specific endpoints and parameters).
Build domain-specific endpoints and params files and reuse across targets.
Let's apply the methodology & hack!
Step one: Getting a feel for things
Has anyone else written a disclosure or writeup? Check Google, HackerOne, OpenBugBounty.
https://www.google.com/?q=domain.com+vulnerability
https://www.hackerone.com/hacktivity
https://www.openbugbounty.org/
Analyze the main website flow: login, register, upload, etc.
Questions to ask on first look:
Can I login with social media?
Do different geolocations affect login options?
What characters are allowed in inputs?
Are inputs reflected anywhere (bio, posts)?
Does the mobile signup use a different codebase?
Key features to inspect:
Registration: required fields, where reflected, photo upload handling, display name and bio filtering.
Social login: OAuth implementation and what info is trusted.
Allowed characters: try
<script, unicode,%00,%0d.Check login redirects and parameters (
returnUrl,goto, etc).Inspect JS files for endpoints and hidden functionality.
Use Google dorks to see what Google indexes about registration/login pages.
Step two: Expanding the attack surface
Run subdomain scanning tools and look for domains with functions (login, upload, api, developer, etc).
Google dork common keywords:
login, register, upload, contact, feedback, join, signup, profile, user, comment, api, developer, affiliate, careers, upload, mobile, upgrade, passwordreset.Dork for file extensions:
php, aspx, jsp, txt, xml, bak.Search GitHub, Shodan, BinaryEdge for leaked secrets (api_key, api_secret, passwords).
Use robots.txt (via scanning) to find endpoints the site owner didn't want indexed.
Use Wayback Machine to find historical endpoints and files.
Fuzz directories and files with FFUF and CommonSpeak.
Check GET vs POST differences — vulnerabilities may exist only for one method.
Step three: Automate, rinse & repeat
Use recon automation (e.g., lazyrecon by NahamSec): https://github.com/nahamsec/lazyrecon
Stay updated on new programs and disclosures (Twitter feeds, mailing lists).
Follow writeups and communities to learn new tricks and bypasses.
Build and refine custom wordlists and tooling for recurring targets.
Useful resources & links
Common payloads and bypasses:
https://github.com/swisskyrepo/PayloadsAllTheThings
https://github.com/masatokinugawa/filterbypass/wiki/Browser's-XSS-Filter-Bypass-Cheat-Sheet
https://d3adend.org/xss/ghettoBypass
Open Redirect payloads: https://github.com/cujanovic/Open-Redirect-Payloads/blob/master/Open-Redirect-payloads.txt
Recon & tooling:
CertSpotter API: https://certspotter.com/api/v0/certs?domain=domain.com
URL encoding reference: http://www.degraeve.com/reference/urlencoding.php
APK scan: https://apkscan.nviso.be/
PublicWWW (search HTML/JS/CSS): https://publicwww.com/
Pentester resources: https://pentester.land
Bug bounty writeups: https://medium.com/bugbountywriteup
Sandboxes:
https://www.jsfiddle.net
https://www.jsbin.com/
Recon helpers:
https://www.yougetsignal.com/tools/web-sites-on-web-server/
https://apkscan.nviso.be/
https://publicwww.com/
Last updated