FEKOJEWAN — Independent Bug Bounty Hunter & Security Researcher

METHODICAL RIGOR

Research Methodology

A disciplined 8-step security workflow. Security research conducted as a structured engineering discipline, prioritizing non-destructive validation, clear evidence, and actionable remediation.

01

Scope Understanding & Invariant Mapping

Before sending a single probe, the authorized boundaries, tenant isolation models, and business objectives are thoroughly analyzed.

KEY ACTIVITIES:• Define explicit allowed domains, subdomains, API paths, and excluded hosts.• Map out user roles, subscription tiers, and multi-tenant organizational hierarchies.• Review program disclosure policies and designated safe harbor commitments.

02

Attack Surface & Topology Reconnaissance

Building a structural mental model of the application rather than running noisy automated vulnerability scanners.

KEY ACTIVITIES:• Passive inspection of JavaScript bundles, sourcemaps, and client API endpoints.• Documentation of authentication state transfers, cookies, and OAuth redirect URIs.• Identification of background queues, third-party webhook receivers, and microservice gateways.

03

Hypothesis Development

Formulating precise, falsifiable theories about where developer assumptions might diverge from runtime reality.

KEY ACTIVITIES:• Can a user in Tenant A supply an ID belonging to Tenant B to nested sub-resolvers?• Does the payment or credit deduction step verify idempotency atomically in the database?• Are deserialized request parameters strictly restricted to safe Data Transfer Objects?

04

Controlled & Non-Destructive Validation

Executing focused test cases designed to confirm or disprove the hypothesis with minimal operational footprint.

KEY ACTIVITIES:• Crafting minimal HTTP requests containing only the necessary parameters.• Respecting rate limits and avoiding heavy concurrency that could degrade service.• Testing solely against researcher-owned test accounts and dummy sandbox records.

05

Technical Impact Assessment

Distinguishing theoretical bugs from actual security risks to prevent alert fatigue for triage teams.

KEY ACTIVITIES:• Determining whether the finding permits unauthorized read, modification, or elevation.• Evaluating real-world prerequisite barriers (e.g. required privileges, user interaction).• Assigning realistic CVSS scores based on demonstrable exploitability.

06

Deterministic Evidence Collection

Documenting clear, self-contained reproduction artifacts so developers can immediately replicate and fix the issue.

KEY ACTIVITIES:• Raw HTTP request and response pairs with sensitive personal details redacted.• Deterministic curl commands or minimal Python reproduction scripts.• Precise code references or root-cause explanations when open source or client-accessible.

07

Responsible & Coordinated Disclosure

Engaging directly with security teams through established disclosure channels.

KEY ACTIVITIES:• Submitting structured reports via bug bounty platforms, security.txt, or PGP-encrypted email.• Maintaining prompt and constructive communication during triage.• Respecting embargo periods while engineering teams prepare and roll out patches.

08

Verification & Remediation Review

Validating that the deployed patch truly fixes the architectural root cause rather than just filtering a symptom.

KEY ACTIVITIES:• Re-testing the original attack vector in staging or production after fix confirmation.• Checking whether adjacent endpoints or nested methods remain vulnerable.• Collaborating on long-term prevention guidelines and unit/integration test cases.

Put this methodology to work on your systems

Submit an authorized Web or API target to the Challenge Me intake pipeline.

Submit Scope