Capstone Project 2: Bug Bounty Simulation — ShopStack E-Commerce

Project Overview

This capstone places you in the role of an independent bug bounty hunter participating in ShopStack's public vulnerability disclosure program. Unlike the structured, phased approach of a penetration test (Capstone 1), bug bounty hunting demands a different mindset: you work independently, prioritize targets based on your own judgment, and your reward — both in grades and in a real program — depends entirely on the quality and impact of the vulnerabilities you discover and report.

ShopStack is a fictional mid-size e-commerce platform serving approximately 50,000 active merchants and processing over $2 billion in annual transaction volume. Their platform handles sensitive financial data (payment cards, bank accounts), personal information (customer profiles, shipping addresses), and business-critical operations (inventory management, order fulfillment, merchant payouts). A vulnerability in ShopStack does not just affect ShopStack — it potentially compromises every merchant and customer on the platform.

This project focuses specifically on web application and API security testing, cloud misconfiguration hunting, and business logic vulnerability discovery. You will apply the web hacking, API testing, and cloud security skills covered throughout this textbook in an environment that rewards creativity, persistence, and clear communication.

Estimated Duration: 30–45 hours across 2–3 weeks.

Learning Objectives

Upon completing this capstone, you will be able to:

1. Analyze a bug bounty program's scope and rules to maximize effective testing time while avoiding scope violations.
2. Discover and validate web application vulnerabilities across multiple categories including authentication flaws, injection attacks, access control issues, and business logic errors.
3. Test REST and GraphQL APIs for security weaknesses including broken object-level authorization, mass assignment, rate limiting failures, and injection vectors.
4. Identify cloud infrastructure misconfigurations affecting data confidentiality and service integrity.
5. Assess payment flow security and business logic for vulnerabilities that automated scanners cannot detect.
6. Write professional bug bounty reports that clearly communicate vulnerability impact, provide reliable reproduction steps, and suggest effective remediation.
7. Triage and prioritize findings according to real-world impact, distinguishing between impressive-sounding but low-impact issues and subtle but devastating vulnerabilities.

ShopStack Platform Description

Company Background

ShopStack was founded in 2017 as a "Shopify alternative" targeting small-to-medium businesses that want more control over their e-commerce infrastructure. The platform provides hosted storefronts, payment processing, inventory management, shipping integration, and analytics. ShopStack differentiates itself by offering extensive API access and a plugin marketplace where third-party developers can extend platform functionality.

The engineering team consists of approximately 80 developers. The platform was originally built as a monolith and has been gradually migrated to a microservices architecture — a migration that is roughly 70% complete. This transition period is relevant because architectural boundaries are still being established, and some legacy code paths bypass newer security controls.

Technical Architecture

Frontend: - Customer-facing storefronts: Server-side rendered React (Next.js) applications. Each merchant gets a subdomain: {merchant-slug}.shopstack.example.com. - Merchant dashboard: Single-page React application at dashboard.shopstack.example.com. - Admin panel: Internal tool at admin.shopstack.example.com (out of scope for bug bounty, but information leakage revealing its existence is reportable).

Backend API: - Primary REST API: api.shopstack.example.com/v2/ — serves the merchant dashboard, mobile apps, and third-party integrations. Documented at docs.shopstack.example.com. - GraphQL API: api.shopstack.example.com/graphql — newer API surface used by the React frontend. Supports introspection (query __schema). - Webhook system: ShopStack sends webhooks to merchant-configured endpoints for order events, inventory changes, and payout notifications. - Authentication: OAuth 2.0 for third-party apps, JWT tokens for first-party applications, API keys for merchant server-to-server integrations.

Data Storage: - PostgreSQL 14: Primary relational database for orders, products, customers, and merchant accounts. - Redis 7: Session storage, rate limiting counters, caching layer, and real-time inventory locks. - Amazon S3: Product images, merchant documents (tax forms, identity verification), invoice PDFs, and data export files. - Elasticsearch: Product search index, order search, and analytics data.

Cloud Infrastructure (AWS): - Application servers: ECS Fargate containers in us-east-1. - Database: RDS PostgreSQL with read replicas. - CDN: CloudFront for static assets and product images. - Serverless functions: Lambda for image processing, PDF generation, data export, and webhook delivery. - Message queue: SQS for asynchronous order processing and inventory updates. - Secrets: AWS Secrets Manager for database credentials and API keys (but older Lambda functions may still use environment variables).

Payment Processing: - Stripe Connect integration for payment processing and merchant payouts. - PCI DSS compliance achieved through Stripe Elements (client-side tokenization) — ShopStack never directly handles raw card numbers. - However, ShopStack does store: last four digits of card numbers, billing addresses, transaction amounts, and payout bank account details.

Mobile Applications: - iOS and Android apps for merchants (inventory management, order notifications, sales analytics). - Mobile apps communicate exclusively through api.shopstack.example.com.

Bug Bounty Program Rules

Program Scope

In Scope:

Out of Scope:

Reward Tiers

Safe Harbor

ShopStack will not pursue legal action against researchers who: - Act in good faith and comply with this policy. - Test only within the defined scope. - Do not access, modify, or delete real customer or merchant data. - Report vulnerabilities promptly and do not publicly disclose before ShopStack has had 90 days to remediate. - Do not use automated tools at rates exceeding 10 requests per second. - Immediately stop testing if they inadvertently access real user data and report the access.

Test Accounts

The following test accounts are provided for authenticated testing:

• Merchant Account: testmerchant@shopstack.example.com / credentials provided at program start. This account operates a test store at test-store.shopstack.example.com with synthetic products, orders, and customers.
• Customer Account: testcustomer@shopstack.example.com / credentials provided at program start. This account has order history and saved payment methods (Stripe test cards) on the test store.
• API Key: A test API key with standard merchant permissions, provided at program start.
• OAuth App: A registered OAuth application for testing the third-party integration flow.

You may create additional test accounts using + email addressing (e.g., testmerchant+alt1@shopstack.example.com) to test multi-tenant isolation.

Target Areas to Investigate

The following sections describe the five primary target areas for your investigation. Each area includes guidance on what to look for, common vulnerability patterns, and specific testing suggestions. These are starting points — experienced bug bounty hunters go beyond the obvious targets.

Target Area 1: Authentication and Session Management

ShopStack supports multiple authentication mechanisms across different user types and interfaces. Authentication complexity is a reliable source of vulnerabilities.

What to Test:

• Password Reset Flow: Examine the password reset mechanism for token predictability, token reuse, race conditions, and host header injection. Can you reset another user's password by manipulating the reset request?
• OAuth 2.0 Implementation: Test the OAuth flow for redirect_uri validation bypass, state parameter handling, token leakage through referrer headers, and scope escalation. Can a malicious third-party app gain more permissions than authorized?
• JWT Token Security: Analyze JWT tokens for algorithm confusion attacks (alg:none, RS256 to HS256 switching), weak signing keys, missing expiration, and token revocation effectiveness. What happens when a user changes their password — are existing tokens invalidated?
• Session Management: Test for session fixation, concurrent session handling, session persistence after logout, and cookie security attributes (HttpOnly, Secure, SameSite).
• Multi-Factor Authentication: If MFA is available, test for bypass techniques: backup code brute-forcing, MFA fatigue through repeated push notifications, MFA bypass through API endpoints that don't enforce MFA.
• Account Takeover Vectors: Combine findings across authentication mechanisms. Can you chain a weak password reset with a redirect vulnerability to achieve account takeover?

Specific Tests to Attempt: - Register two merchant accounts and verify complete session isolation between them. - Capture a JWT token, decode it, identify the signing algorithm, and check whether the secret is weak enough to crack offline. - Attempt to use a merchant's API key to access the merchant dashboard endpoints intended for session-authenticated users — are these authentication mechanisms properly separated? - Test whether the GraphQL API enforces the same authentication requirements as the REST API for equivalent operations.

Target Area 2: API Security (REST and GraphQL)

ShopStack's APIs are the backbone of the platform, and the dual REST/GraphQL architecture creates a large and potentially inconsistent attack surface.

What to Test:

• Broken Object-Level Authorization (BOLA/IDOR):
• Enumerate REST endpoints and test each one for IDOR by substituting resource IDs from your test account with IDs from another merchant.
• In GraphQL, test whether queries respect authorization boundaries. Can you query order(id: "other-merchant-order-id") and receive data?

• Pay special attention to endpoints that return nested objects — an endpoint might correctly restrict the top-level resource but leak data through related objects (e.g., /api/v2/orders/{id} might restrict order access but include the customer's full profile in the response).

• Broken Function-Level Authorization:

• Identify administrative or privileged API endpoints by examining JavaScript source maps, API documentation, and network traffic patterns.
• Test whether merchant-level API keys can access endpoints intended for internal use.

• Look for HTTP method-based access control issues: can you PUT or DELETE resources you can only GET?

• Mass Assignment:

• Test POST and PUT endpoints for mass assignment by adding unexpected fields. Can you set is_admin: true, plan: "enterprise", commission_rate: 0, or verified: true in API requests?

• In GraphQL mutations, test whether the input type accepts fields beyond what the documentation specifies.

• GraphQL-Specific Attacks:

• Test for introspection exposure in production (query {__schema{types{name}}}).
• Attempt query depth and complexity attacks to identify resource exhaustion possibilities (deeply nested queries, alias-based batching).
• Look for field suggestions in error messages that reveal undocumented fields.

• Test batch queries for authentication bypass — can you batch an authenticated query with an unauthenticated query to access protected data?

• Rate Limiting and Abuse:

• Identify endpoints that lack rate limiting, particularly login, password reset, coupon code validation, and search.

• Test whether rate limits are per-user, per-IP, per-API-key, or global. Can you bypass rate limits by rotating API keys or using the GraphQL endpoint instead of REST?

• Injection Attacks:

• Test all input fields for SQL injection, including less obvious vectors: sort parameters, filter expressions, search queries, and webhook URLs.
• Test for NoSQL injection in any MongoDB-backed endpoints (search, analytics).
• Test for server-side template injection (SSTI) in any feature that renders user-controlled templates (email notifications, storefront customization).
• Test for SSRF through any feature that fetches external resources: webhook testing, product image import from URL, CSV import with URL fields.

Specific Tests to Attempt: - Use GraphQL introspection to map the complete API schema. Compare with the documented REST API to identify undocumented operations. - Create two merchant accounts. From Merchant A's session, attempt to read and modify Merchant B's products, orders, customers, and payout settings. - Find the endpoint that processes merchant payout bank account changes. Test it for IDOR — can you change another merchant's payout destination? - Test the webhook delivery system for SSRF: configure a webhook URL pointing to http://169.254.169.254/latest/meta-data/ and check whether the response is logged or returned.

Target Area 3: Payment Flow and Business Logic

Business logic vulnerabilities are the highest-value findings in bug bounty programs because they require human intelligence to discover — automated scanners cannot find them. ShopStack's payment processing involves complex interactions between the frontend, backend, Stripe, and merchant configurations.

What to Test:

• Price Manipulation:
• Trace the complete checkout flow from "Add to Cart" through "Payment Confirmation." At what point is the price determined — client-side or server-side? Can you modify the price in transit?
• Test for race conditions in inventory management. Can you purchase an item by submitting simultaneous requests, exploiting a time-of-check-to-time-of-use (TOCTOU) vulnerability?

• Examine coupon and discount code handling. Can you apply the same coupon multiple times? Can you apply percentage discounts that exceed 100%? Can you use negative quantities or prices?

• Payment Processing Logic:

• Analyze the Stripe integration. Does ShopStack validate the payment amount on the server side after Stripe confirms the charge, or does it trust the client-reported amount?
• Test the refund flow. Can you initiate a refund for more than the original order amount? Can you refund to a different payment method?

• Examine the merchant payout calculation. If you manipulate the commission rate or transaction amount in API requests, does the payout amount change?

• Order Manipulation:

• Test whether you can modify an order after payment (change shipping address, add items, change quantities) without additional payment.
• Examine the order cancellation flow. Can you cancel an order after it has shipped and still receive a refund?

• Test the digital product delivery flow. Can you access digital downloads without completing payment by directly accessing the download URL?

• Gift Card and Store Credit Abuse:

• If ShopStack supports gift cards, test for balance manipulation, code predictability, and transfer abuse.

• Can you generate store credit through return fraud (returning items that were purchased with store credit)?

• Multi-Merchant Isolation:

• A critical business logic concern: can a customer on one merchant's store access or affect another merchant's store data?
• Can a merchant's storefront customization (JavaScript, CSS) be used to attack customers of other merchants on the platform?

Specific Tests to Attempt: - Complete a purchase for a $100 item. Intercept the Stripe payment intent creation request. Modify the amount to $1. Does the order succeed at the reduced price? - Apply a 20% discount code. Then, in the same session, attempt to modify the coupon value through the API before checkout completes. - Create an order, then send 50 simultaneous requests to apply a one-time-use coupon code. Does the race condition allow the coupon to be applied multiple times? - Test whether the webhook that notifies the merchant of a new order includes sufficient data integrity protections. Can you forge a webhook notification?

Target Area 4: Cloud Resource Misconfigurations

ShopStack's AWS infrastructure is accessible only through vulnerabilities in the application layer — you are not provided with AWS credentials. However, application-level bugs frequently lead to cloud resource exposure.

What to Test:

• S3 Bucket Misconfigurations:
• Identify S3 buckets used by ShopStack through analyzing asset URLs, JavaScript source code, API responses, and error messages.
• Test discovered buckets for public listing, public read access, and public write access.
• Check for directory listing enabled on buckets that host product images — can you enumerate all merchants' uploaded files?

• Test whether pre-signed URLs have appropriate expiration times. A pre-signed URL for a tax document that remains valid for 30 days is a vulnerability.

• SSRF to Cloud Metadata:

• Any SSRF vulnerability discovered in Target Area 2 should be tested for access to the AWS Instance Metadata Service (IMDS) at http://169.254.169.254/.
• If IMDS v1 is accessible (no token required), retrieve IAM role credentials and document what those credentials can access.

• Check whether the Lambda function URLs reveal environment variables containing secrets.

• Exposed Cloud Resources:

• Search for exposed Elasticsearch clusters, Redis instances, or RDS instances that may be accessible due to overly permissive security groups.
• Check for CloudFront misconfigurations that bypass origin access controls.

• Look for S3 buckets used for data exports that may contain merchant or customer data.

• Infrastructure Information Disclosure:

• Examine HTTP headers, error messages, and API responses for AWS account IDs, region names, resource ARNs, and internal hostnames.
• Check whether CloudFormation or Terraform state files are accessible in any S3 bucket.

Specific Tests to Attempt: - Collect all S3 URLs referenced in the application. For each bucket, test: GET https://{bucket}.s3.amazonaws.com/, GET https://{bucket}.s3.amazonaws.com/?list-type=2, and test with various HTTP methods. - If you find product image URLs following a pattern like https://cdn.shopstack.example.com/products/{merchant-id}/{image-hash}.jpg, attempt to enumerate other merchants' images by varying the merchant-id. - Test the product image upload feature: what happens if you upload a very large file? What happens if you upload an SVG containing JavaScript? What happens if you upload a file with a manipulated Content-Type header?

Target Area 5: Client-Side Vulnerabilities

Client-side vulnerabilities on an e-commerce platform can enable credential theft, payment card harvesting (Magecart-style attacks), and merchant account takeover.

What to Test:

• Cross-Site Scripting (XSS):
• Test every user-controllable input that is reflected in HTML: product names, descriptions, review text, merchant profile fields, search queries, URL parameters, and error messages.
• Pay special attention to stored XSS in fields that are rendered across contexts: a product name entered by a merchant that is displayed to customers, rendered in the admin dashboard, and included in email notifications.
• Test for DOM-based XSS by auditing client-side JavaScript. React applications are generally resistant to XSS, but dangerouslySetInnerHTML, URL handling in href attributes, and custom template rendering can introduce vulnerabilities.

• Test for mutation XSS (mXSS) if the application uses HTML sanitization — sanitizers can be bypassed with carefully crafted payloads.

• Cross-Site Request Forgery (CSRF):

• Identify sensitive actions that rely on cookie-based authentication and test for CSRF token presence and validation.
• Test whether the SameSite cookie attribute is set and whether it effectively prevents cross-origin requests.

• Pay attention to state-changing GET requests (if any exist) — these are CSRF-vulnerable regardless of token protection.

• Client-Side Data Exposure:

• Examine JavaScript bundles and source maps for hardcoded API keys, internal endpoints, or developer comments revealing security-relevant information.
• Check browser local storage and session storage for sensitive tokens or user data that should be in HttpOnly cookies.

• Review the Content Security Policy (CSP) for weaknesses that could enable XSS escalation.

• Subdomain Takeover:

• Enumerate ShopStack subdomains (merchant storefronts, API endpoints, development environments).

• Check for CNAME records pointing to deprovisioned cloud services (Heroku, GitHub Pages, S3, Azure) that could be claimed by an attacker.

• Clickjacking:

• Test whether the merchant dashboard and payment pages are frameable. Missing X-Frame-Options or inadequate frame-ancestors CSP directives on sensitive pages can enable clickjacking attacks.

Specific Tests to Attempt: - On the test store, create a product with an XSS payload in the product name. Check whether it executes in: the storefront product page, the merchant dashboard order view, the customer order confirmation email, and the API response. - Find the merchant dashboard's JavaScript bundle. Check for source maps (appending .map to the bundle URL). If accessible, review the source code for hardcoded secrets, API endpoints, and developer comments. - Enumerate all subdomains of shopstack.example.com using certificate transparency logs. For each subdomain, check the DNS records and verify that the referenced service is still active.

Required Deliverables

You must submit a minimum of five validated vulnerability findings with complete bug bounty reports. Quality far outweighs quantity — five well-documented, high-impact findings will score higher than fifteen poorly documented low-severity issues.

Bug Bounty Report Template

Each finding must be documented using the following structure:

1. Title A concise, descriptive title that communicates the vulnerability type and its impact. - Good: "IDOR in /api/v2/orders/{id} Allows Any Authenticated Merchant to Read Other Merchants' Order Details Including Customer PII" - Bad: "Broken access control"

2. Severity Assessment Your assessed severity (Critical/High/Medium/Low/Informational) with justification. Reference the reward tier definitions. Include a CVSS 3.1 vector string and score.

3. Affected Component The specific URL, endpoint, parameter, or feature where the vulnerability exists.

4. Description A clear explanation of the vulnerability: what it is, why it exists (your analysis of the root cause), and what security property it violates. Write this for a developer who needs to understand the flaw in order to fix it.

5. Reproduction Steps Numbered, step-by-step instructions that allow ShopStack's security team to reproduce the vulnerability independently. Include: - Exact URLs and HTTP methods. - Complete HTTP request and response pairs (use Burp Suite or browser developer tools to capture these). - Any prerequisites (specific account types, configurations, or states). - Screenshots at each significant step. - For complex or timing-dependent issues, include a proof-of-concept script.

6. Impact Analysis A realistic assessment of the worst-case impact if this vulnerability were exploited by a malicious actor. Consider: - How many users/merchants could be affected? - What data could be exposed? - What financial impact is possible? - Could this be chained with other vulnerabilities for greater impact?

7. Remediation Suggestions Specific technical recommendations for fixing the vulnerability. Where possible, include code-level guidance.

8. References Relevant CWE entries, OWASP classifications, blog posts, or advisories that provide context for the vulnerability type.

Report Quality Expectations

Exemplary Reports are a narrative. They walk the reader through the discovery process, explain the vulnerability in context, provide unambiguous reproduction steps, and offer thoughtful remediation. They demonstrate that the researcher understands not just the technical flaw but its business impact.

Adequate Reports convey the necessary information but may require back-and-forth with the security team to reproduce the issue. They identify the vulnerability correctly but may lack impact analysis or remediation depth.

Insufficient Reports are vague, lack reproduction steps, overstate severity, or describe theoretical attacks without demonstrating exploitability. Reports that say "I found XSS" with a screenshot of an alert box but no context about where, how, and why it matters are insufficient.

Additional Deliverables

Beyond the five individual vulnerability reports, submit:

Grading Rubric

Excellent (90–100%)

• Reconnaissance: Thorough mapping of the attack surface with creative techniques. Technology stack fully identified. Undocumented endpoints discovered. Attack surface analysis demonstrates deep understanding of the application architecture.
• Finding Quality: Five or more findings, with at least two rated High or Critical. Findings demonstrate variety across target areas (not all five from the same category). Each finding is validated, well-documented, and includes realistic impact analysis.
• Report Quality: Reports are clear, complete, and professionally written. Reproduction steps are reliable — a security engineer could reproduce each finding from the report alone. Remediation suggestions are specific and technically sound.
• Methodology: Testing approach is systematic and well-documented. The student demonstrates strategic thinking about where to focus effort for maximum impact. Testing methodology document shows awareness of bug bounty best practices.
• Chain Analysis: At least one vulnerability chain documented, demonstrating how individual findings combine for greater impact. This elevates the work from competent to exceptional.
• Ethical Conduct: All testing within scope. No destructive testing. Real user data not accessed or reported. Rate limits respected.

Good (75–89%)

• Five findings submitted with at least one High-severity issue. Reports are complete and reproducible but may lack depth in impact analysis or remediation. Reconnaissance is adequate but may miss non-obvious attack surface components. Methodology is sound but may focus too narrowly on one target area.

Adequate (60–74%)

• Five findings submitted but predominantly Low or Medium severity. Reports may require additional clarification to reproduce. Reconnaissance covers obvious targets but misses significant areas. Limited variety in vulnerability types — for example, all five findings are XSS variants.

Below Expectations (Below 60%)

• Fewer than five validated findings, or findings that cannot be reproduced from the provided reports. Reports lack essential components (reproduction steps, impact analysis). Severity ratings are inflated without justification. Evidence of scope violations or destructive testing.

Tips for Maximizing Findings

The following guidance comes from experienced bug bounty hunters and is designed to help you work effectively within the constraints of this project.

Think Like a Developer, Not Just an Attacker

Before you start firing payloads, spend time understanding how ShopStack works. Use the application as a legitimate merchant and customer. Create products, process orders, issue refunds, configure webhooks, and customize your storefront. Understanding the intended functionality helps you identify deviations from it.

Focus on Authorization Over Injection

The most impactful vulnerabilities in modern web applications are authorization failures, not injection attacks. Modern frameworks generally handle input sanitization well; they handle authorization poorly because authorization logic is business-specific and cannot be automated by the framework. Invest significant time testing whether API endpoints properly verify that the requesting user is authorized to access the requested resource.

Read the JavaScript

The React frontend is a treasure trove of information. Source maps may expose the complete frontend source code. Even without source maps, minified JavaScript can be analyzed with tools like Webpack Bundle Analyzer, js-beautify, or browser developer tools. Look for: - Hardcoded API endpoints (including internal or pre-production endpoints). - Commented-out features or feature flags that reveal functionality not yet publicly available. - Client-side authorization checks that can be bypassed (because the server should be enforcing authorization, not the client). - Hidden form fields or API parameters not visible in the UI.

Test the Seams

Vulnerabilities cluster at architectural boundaries: between the old monolith and new microservices, between the REST and GraphQL APIs, between the client-side and server-side, between ShopStack's code and Stripe's integration. These "seams" are where assumptions break down and authorization models become inconsistent.

Document Everything in Real Time

Do not rely on browser history and memory. Use Burp Suite's project files to log all traffic. Write notes as you test. When you discover a potentially interesting behavior — even if you are not yet sure it is a vulnerability — document it immediately. Some of your best findings will come from revisiting "interesting but unclear" observations after you understand the application better.

Be Patient with Business Logic

Business logic vulnerabilities are not found in the first hour of testing. They emerge after you deeply understand the application's workflows. The researcher who discovers that manipulating the webhook notification sequence allows order fulfillment without payment has invested hours understanding the order lifecycle. This investment pays disproportionate rewards.

Avoid Common Pitfalls

• Do not flood the program with informational findings. Five missing-header reports do not demonstrate skill. One IDOR report does.
• Do not report theoretical vulnerabilities. "This endpoint might be vulnerable to SQL injection because it uses a query parameter" is not a finding. Demonstrate the injection or do not report it.
• Do not ignore the scope. Testing admin.shopstack.example.com directly is a scope violation. Discovering that a public endpoint leaks information about the admin panel is a valid finding.
• Do not duplicate. Before writing up a finding, search whether the same vulnerability class has been reported on the same endpoint by another researcher (in a real program). In this capstone, each of your five findings should be meaningfully distinct.

Ethical Considerations

Bug bounty hunting occupies a unique ethical position. You are authorized to find and report vulnerabilities, but that authorization comes with responsibilities.

Data Handling: If you discover a vulnerability that exposes real user data (merchant information, customer PII, payment details), do not access more than the minimum necessary to validate the vulnerability. In your report, redact any real user data. If you inadvertently access a large volume of real data, stop immediately and report the access.

Impact Avoidance: Even authorized testing can cause harm. If you discover a SQL injection, demonstrate it with a benign query (SELECT version(), not DROP TABLE orders). If you find an SSRF, access metadata endpoints, not internal databases. The goal is to demonstrate the vulnerability's existence and potential impact without actually causing that impact.

Responsible Disclosure: In a real bug bounty program, you would not publicly disclose findings until the vendor has had time to remediate. In this capstone, treat all findings as confidential within your educational context.

Respect for Other Users: Your test accounts exist in a shared environment. Do not modify, delete, or access other users' test data. If the test environment does not provide complete isolation, be especially careful to limit your testing footprint.

Honesty in Reporting: Report exactly what you found. Do not inflate severity to chase higher rewards. Do not fabricate reproduction steps. Do not claim to have found vulnerabilities that you inferred but did not demonstrate. A bug bounty program's trust in researchers is the foundation of the entire model — protect that trust.

Final Guidance

Bug bounty hunting is one of the most intellectually demanding disciplines in cybersecurity. Unlike penetration testing, where a structured methodology guides your effort, bug bounty hunting rewards creative intuition developed through deep experience. You are competing — with yourself and, in real programs, with thousands of other researchers — for limited rewards on systems that have already been tested by many skilled people.

The findings that remain to be discovered are the ones that require you to think differently. They live in business logic that no scanner checks. They hide behind authorization models that work for 99% of cases but fail at the edges. They emerge when two individually secure features interact in unexpected ways.

This capstone gives you a realistic playground to develop that intuition. Approach it with curiosity, patience, and intellectual honesty. The skills you build here — systematic analysis, creative hypothesis generation, clear technical writing — will serve you whether you pursue bug bounty hunting professionally or apply these skills in any other security role.

This capstone project is designed for educational purposes in a controlled lab environment. All domain names, company names, and scenarios are fictional. Never test applications or services for vulnerabilities without explicit authorization from the system owner.