Detalle del Skill

bugbounty-ideas

Explicitly provides safe, authorized bug bounty research and test hypotheses.

CoincidenciaDirectaRevisado para recompensa por errores
Fuenteyossefsabry/dotfilesFuente externa
Instalaciones reportadas1Solo señal de popularidad

Revisar antes de usar

La revisión automática comprueba relevancia, no seguridad ni respaldo. Lee las instrucciones de la fuente antes de usar este Skill.

Vista previa guardada

SKILL.md

Este extracto es una copia guardada durante la revisión. La fuente externa contiene la versión completa y actual.

---
name: bugbounty-ideas
description: Use when the user wants bug bounty research ideas, authorized hacking/testing hypotheses, vulnerability hunting inspiration, or online writeup synthesis from a README or public bug bounty reports.
---

# Bug Bounty Ideas

## Overview

Use the bundled `README.md` as an index of public bug bounty writeups, then research online sources to turn patterns into safe, authorized testing ideas. The goal is to produce practical hypotheses for a permitted target, not exploit instructions for unauthorized systems.

## When to Use

Use this skill when the user asks for:

- Bug bounty ideas, hunting ideas, or vulnerability research inspiration.
- Online research based on the local `README.md` writeup index.
- Ideas for XSS, CSRF, clickjacking, LFI, subdomain takeover, DoS, authentication bypass, SQLi, IDOR, 2FA, CORS, SSRF, race condition, RCE, buffer overflow, or Android testing.
- Turning public writeups into safe test hypotheses for an authorized program.

## Safety Boundary

Before giving target-specific testing advice, confirm the work is within an authorized bug bounty scope. If scope is unclear, ask for the program scope, allowed assets, test accounts, rate limits, and excluded testing. If the user only wants learning or generic inspiration, keep the output generic and non-operational.

Keep recommendations non-destructive:

- Prefer passive research, test accounts, staging targets, and low-impact validation.
- Avoid weaponized payloads, exploit chains, credential theft, data extraction, persistence, and bypassing rate limits.
- Include stop conditions for ideas that could affect availability, privacy, or integrity.
- Label risky ideas and suggest reading the program rules before testing.

## Workflow

1. Read the bundled `README.md` first. Extract relevant sections and links based on the user's requested vulnerability class, target technology, or program rules.
2. If the user did not name a vulnerability class, pick categories from the README that fit their target surface. Examples: IDOR for object IDs and APIs, XSS for rich text and uploads, SSRF for URL fetchers and webhooks, race conditions for payments or rewards.
3. Search online when a search tool is available. If only URL fetching is available, fetch selected README links and user-provided URLs. Prefer authoritative sources such as HackerOne reports, PortSwigger Web Security Academy, OWASP Testing Guide, vendor docs, and mature researcher writeups.
4. Convert each source into a testing hypothesis. Focus on the vulnerable pattern, where it appears in modern apps, how to validate safely, what evidence to capture, and what impact it could prove.
5. Cross-check ideas against the program scope and rules. Remove anything prohibited or too destructive.
6. Present a concise list of prioritized ideas with sources and next safe steps.

## Search Query Recipes

Use the README category plus target details to form queries:

| Goal | Query pattern |
| --- | --- |
| Find similar public reports | `site:hackerone.com/reports <vulnerability> <technology>` |
| Find learning references | `<vulnerability> PortSwigger Web Security Academy` |
| Find testing methodology | `<vulnerability> OWASP testing guide` |
| Find target-specific risks | `<technology> <vulnerability> bug bounty writeup` |
| Find framework pitfalls | `<framework> security <vulnerability> misconfiguration` |

If search is unavailable, select 3-8 relevant links from `README.md` and fetch them directly.

## Output Format

Use this structure by default:

```markdown
## Scope Check
- Authorization assumption:
- Target/scope used:
- Exclusions or unknowns:

## Research Sources
- README sections used:
- Online sources checked:

## Prioritized Ideas

### 1. <idea name>
- Category: <XSS/IDOR/SSRF/etc.>
- Inspired by: <README link or online source>
- Target surface: <feature or endpoint class>
- Hypothesis: <what might be wrong>
- Safe validation: <non-destructive check>
- Evidence to capture: <screen
Leer la fuente completa en GitHub (abre una página externa)
Contexto

Trabajo relacionado