About Me

Hey! I’m Satyam Pawale, known as @hackersatty in the bug bounty and ethical hacking world. I started bug hunting in 2024, and ever since, I’ve been obsessed with finding vulnerabilities that most people overlook.

My goal with this blog is to share real-world bug bounty experiences so other hunters can learn the techniques, tools, and mindset required to succeed — while staying ethical and responsible.

This case is about how I found critical admin endpoint vulnerabilities that allowed direct, unauthorized access to sensitive backend pages and data.

Summary

A race condition in the GraphQL CreateNotification flow allows many identical notification records to be created for the same (email, notificationType) pair by sending the same mutation concurrently. The backend performs a non-atomic existence check + insert (or lacks a uniqueness constraint), so parallel requests each succeed and create duplicate rows. Impact includes duplicate emails, queue exhaustion, corrupted metrics, and amplified downstream processing. Fix by enforcing atomic deduplication (DB unique constraint, upsert, or transactional locking) and canonicalizing inputs server-side.

Overview

While testing the notifications feature on a sanitized test instance, I discovered that sending the exact same CreateNotification GraphQL mutation near-simultaneously results in multiple identical notification records. The web UI may include client-side deduplication for UX, but the server accepts every concurrent request and persists a row per request because there is no server-side atomic deduplication or uniqueness enforcement.

All artifacts in this write-up are sanitized: domain names and identifiers use hackersatty.com and no real emails or tokens are included.

Vulnerability —

Race condition / missing server-side uniqueness: concurrent CreateNotification GraphQL mutations for the same canonical (email, notificationType) create duplicate database records.

Why this matters

• Duplicate emails — recipients receive the same notification multiple times (spam, reputational risk).

• Queue & worker load — duplicate rows trigger duplicate processing and waste resources.

• Analytics pollution — duplicate rows inflate counts and break metrics.

• Downstream amplification — exports, reporting, or workflows iterating over rows are multiplied.

• Highly automatable — a script or proxy tool can reliably create many duplicates.

Best reproduction scenario

Preconditions

• Valid test account on the portal.

• Active session cookie or Authorization bearer token (the same session used by the UI).

• Intercepting proxy or HTTP client that can replay requests concurrently (Burp Repeater, curl with xargs -P, Python aiohttp script, etc.).

• Testing done only on authorized environments.

Steps

1. Log into the portal at vendor.hackersatty.com with a test account.

2. Dashboard → Settings → Notifications → Add notification (open the modal).

3. Fill notification type (example: ACCOUNT_UPDATES) and a placeholder email (sanitized).

4. Click Save once — confirm a single entry is created (expected).

5. Start an intercepting proxy and perform the same Add action again to capture the GraphQL mutation for CreateNotification.

6. Send the captured POST /graphql request to the proxy’s Repeater (or save the raw request).

7. Clone the captured request many times (e.g., 5–20 identical copies).

8. Use Send group (Parallel) in Burp Repeater (or run the copies concurrently via a script) so they hit the server within milliseconds of each other.

9. Observe: each response returns success (HTTP 200 + GraphQL create payload).

10. Refresh the Notifications UI — multiple identical notification rows appear for the same (email, notificationType) equal to the number of successful concurrent requests.

Sanitized PoC — Request (GraphQL mutation)

Sanitized PoC — Typical Response (each concurrent request returns same success)

Each parallel request returns a created payload and, after refresh, multiple identical notification rows exist in the UI.

Exactly how the race condition happens (technical explanation)

1. Non-atomic check-then-insert: the server likely performs if not exists then insert.

2. Concurrency window: when multiple identical requests arrive simultaneously, each executes the existence check before any concurrent inserts commit; each sees “no existing row” and proceeds to INSERT.

3. No DB uniqueness constraint: the DB lacks a uniqueness constraint on (canonical_email, notification_type), so all inserts succeed.

4. Outcome: the application returns “created” for each request; multiple identical records are persisted.

5. Symptoms: N UI rows for N concurrent requests; duplicated processing downstream.

This is the classic race condition between check and insert under concurrency — the fix is to make creation atomic at the storage layer or to serialize the creation path.

Techniques & tools used (methodology)

• Intercepting proxy: Burp Suite (Proxy + Repeater) with Send group (Parallel).

• Alternative concurrency methods: curl with xargs -P, Python aiohttp or threaded requests, wrk/hey.

• Verification: compare number of created rows in UI to number of concurrent requests; inspect GraphQL responses for created payloads.

• Sanitization: remove tokens, emails, and PII from stored artifacts.

• Optional automation: small async script that sends identical POSTs concurrently to reproduce in staging.

• 

Concrete fixes (prioritized)

1) Enforce uniqueness at the database layer (recommended)

Create a unique index on canonicalized email + notification_type:

This guarantees the storage layer prevents duplicates under concurrent load.

2) Use atomic upsert (ON CONFLICT)

Preferred pattern:

Or ON CONFLICT DO NOTHING followed by SELECT the existing row if you need to return it.

3) Server-side canonicalization

Always canonicalize emails server-side (trim + lowercase + unicode normalize) before checks or inserts.

4) Optional: idempotency token

If clients can provide an idempotency key, enforce it server-side to dedupe create attempts. This is most suitable for API clients rather than basic UI clicks.

5) Transactional locking / advisory locks

If ON CONFLICT is not available, use transactional serialization or an advisory lock keyed by (account_id, canonical_email, notification_type) to serialize creation. This is less desirable than DB uniqueness + upsert.

Pseudocode — atomic upsert (preferred)

Detection & monitoring recommendations

• Alert on spikes in notifications creation per account or per email.

• Instrument unique-violation metrics after adding constraints to detect attempted duplicates.

• Audit logs: record create attempts, client IPs, and request ids for concurrent patterns.

• Queue monitoring: track message queue length and worker backlogs triggered by notification rows.

Safe remediation rollout plan

1. Immediate

   • Canonicalize emails server-side (lowercase + trim).

   • Add rate limits to the create endpoint.

2. High priority

   • Clean existing duplicates (see dedupe plan below).

   • Create a unique index concurrently and change create flow to INSERT ... ON CONFLICT.

3. Post-fix

   • Run dedupe migration in controlled batches and add monitoring.

Dedupe migration (safe approach)

1. Backup the table.

2. Identify duplicates:

3. Keep one canonical row (e.g., earliest created_at) and delete others in batches:

4. Validate referential integrity and update dependent tables if necessary. Run in small batches with an audit trail.

Example automated reproduction script (sanitized, Python async)

For authorized testing only — do not run against production without permission.

This script sends 10 concurrent create requests; on an affected system you would see multiple created rows.

Short checklist to verify the fix in staging

1. Add canonicalization and upsert logic + unique index in a branch.

2. Run the staging app and attempt the same parallel test (Burp Repeater Send group or the async script).

3. Confirm only one notification row exists per canonical (email, notificationType) after the concurrent attempts.

4. Monitor logs and unique-violation metrics; expect zero unhandled constraint errors in normal flow.

5. Run the dedupe migration if historical duplicates exist and then create the index.

Summary —

1. Enforce uniqueness at the DB layer: create a unique index on canonicalized (lower(email), notification_type).

2. Make creation atomic: use INSERT ... ON CONFLICT (upsert) or equivalent so concurrent creates cannot produce duplicates.

3. Canonicalize inputs server-side: trim and lowercase emails and return the existing resource or a clear response when duplicates are attempted.

Final Thoughts

This case is a perfect reminder that even mature applications can overlook concurrency edge cases that don’t show up in regular testing. Client-side validation or simple “check-before-insert” logic might appear sufficient, but when operations run in parallel, the tiniest race window can lead to large-scale data integrity issues.

What made this bug particularly impactful is that it didn’t rely on exotic conditions or privilege escalation — just timing. By coordinating concurrent identical requests, an attacker could manipulate backend logic in ways that normal single-threaded testing would never reveal.

In real-world systems where notifications, transactions, or queue-based processes are triggered by new records, such duplication can have serious downstream effects — from flooding users with redundant messages to distorting analytics or overloading task queues.

Building truly robust APIs requires more than input validation; it demands atomic operations, proper database constraints, and a mindset that anticipates concurrency. Race conditions often hide in plain sight, but once discovered, they offer some of the most valuable lessons for improving backend resilience.

In short, always think in parallel — because your attackers certainly will.

Introduction

If you’re a bug bounty hunter, JavaScript js files should be your best friends. They’re often overlooked but loaded with critical clues like hidden API endpoints, hardcoded secrets, and sensitive directories.

In this guide, I’ll walk you through how I use JavaScript file analysis to find real vulnerabilities and boost my bug bounty payouts. You’ll learn practical regex commands, tooling, and techniques to automate this process—even if you’re just getting started in bug bounty hunting.

Why JavaScript Files Matter

JavaScript (JS) files aren’t just for front-end logic. Developers often leave sensitive info like:

• Internal API routes

• Auth tokens or API keys

• Endpoints not listed in Swagger docs

• Logic that reveals hidden features

They can expose the entire backend structure, giving you a big advantage during recon.

Step 1: How to Read and Download JavaScript Files

You can find JavaScript files by opening browser dev tools, going to the Network tab, and filtering for .js. Copy their URLs or use tools like:

Other tools to automate JS collection:

• waybackurls

• gau

• subjs

Step 2: Extract API Endpoints and Directories

JS files often contain relative or full API paths. Here’s a quick way to pull them:

Look for:

These could be unprotected routes or useful for further attacks like IDOR or SSRF.

Step 3: Detect HTTP Methods

APIs don’t only use GET. JS files show all HTTP verbs like POST, PUT, DELETE:

To extract them automatically:

Look for dynamic methods or hidden admin requests.

Step 4: Search for Hardcoded Secrets

Sometimes developers leave keys right inside the JS. Use this to find them:

What you might find:

• Firebase keys

• AWS credentials

• JWT secrets

• Stripe tokens

Also try searching for these keywords:

Step 5: Automate the Entire Process

Tools That Help You Hunt Faster:

• LinkFinder – Extract endpoints from JS

• SecretFinder – Find secrets, keys, and tokens

• JSleak – Powerful tool for JS recon

• catjs – Highly customizable regex-based JS analyzer

Example Workflow:

Step 6: Fuzzing Discovered Endpoints

Once you’ve collected endpoints from JS, test them using:

• ffuf for directory fuzzing

• Burp Intruder for parameter injection

• Nuclei for known vulnerabilities

You might discover:

• Unauthenticated access

• Broken access control (IDOR)

• Debug or dev-only APIs

• Misconfigured routes

Step 7: Analyze JavaScript for Parameter Names and Sensitive Variables

When developers write frontend JavaScript, they often pass user input or internal values as parameters to API calls or functions. These variable names can help you craft smarter attacks like:

• Parameter pollution

• IDOR

• Open redirect

• XSS

🔍 What to Look For:

Look for variable names in JS code that might indicate sensitive input, such as:

These are goldmines — especially when passed to backend APIs or appended to URLs.

🛠️ Regex to Extract Suspect Variables:

Run this in your downloaded JS files:

You’ll often catch lines like:

🎯 Why This Matters for Bug Bounty

Once you know the exact parameter names being used, you can test them with tools like:

• Burp Repeater – Manually inject or override params

• ffuf or ParamSpider – Fuzz for parameter-based bugs

• Arjun – Auto-discovers hidden HTTP parameters

For example:

You might discover parameters like:

• admin=true

• access=internal

• debug=1

All because the JS revealed them!

Best Practices

• Always prettify JavaScript code for better readability (jsbeautifier, online formatters)

• Respect robots.txt and terms of service

• Don’t report fake issues—test thoroughly and reproduce

• Use clear write-ups with request/response, impact, and remediation

Bonus: Real Bug Bounty Report from JavaScript Analysis

I once found a hidden admin dashboard /admin/internal/config from a JS file. No auth, full access to user records. Reported it → $1000 payout.

Tools used:

• Burp Suite

• LinkFinder

• Manual JS review

Conclusion

If you want to be a successful bug bounty hunter, you must master JavaScript analysis. It’s one of the highest ROI areas in recon. Start small—analyze one file, extract endpoints, look for secrets, automate what works.

Stick with it. I started just a year ago, and now I consistently find high-severity bugs through JS analysis.

Keywords in This Article:

• read javascript file

• javascript js file

• bug bounty hunter

• bug bounty reports

• learn bug bounty hunting

• bug bounty course

• bug bounty writeup

• bug bounty tools

• bug bounty for beginners

• javascript file analysis

Internal Links

• My Internal Blogs

External Resources:

• LinkFinder on GitHub

• SecretFinder

• JSLeak

By Satyam Pawale (@hackersatty)

About Me

Hey security enthusiasts! I’m Satyam Pawale, better known in the cybersecurity and bug bounty community as @hackersatty. I specialize in identifying real-world security vulnerabilities in web applications using smart reconnaissance, API testing, and JavaScript analysis and Privilege Escalation. I began my bug bounty journey in 2024 and have been passionate about securing web systems ever since.

Privilege Escalation in GraphQL: How I Gained Unauthorized Admin Access

In the world of modern APIs, GraphQL has become increasingly popular for its flexibility and efficiency. However, this flexibility often comes at the cost of security if not implemented properly. One common issue is where a user with lower privileges is able to perform actions or access data meant for higher-privileged users.

In this detailed blog, I will walk you through a real-life bug bounty scenario where a user with a “finance” role was able to exploit GraphQL endpoints to gain unauthorized access to admin data. This exploit highlights critical lapses in role-based access control (RBAC) and shows why it’s essential to validate permissions at every level of API design.

What is Privilege Escalation in GraphQL?

Privilege escalation in GraphQL typically refers to an attacker manipulating queries or tokens in a way that allows them to gain access to data or functionality beyond what their role should permit. This usually happens because of misconfigured access control on the backend or poor handling of user roles within queries and mutations.

GraphQL schemas expose a lot of information through introspection. If the API isn’t properly locked down, a user can query for schema metadata, discover sensitive fields, and craft malicious queries even with a low-privilege token.

Background: The Application I Tested

The application was a business management platform with GraphQL-based APIs. Users were segmented by roles: admin, finance, operations, and customer support. The finance role was intended only to view transaction reports and generate invoices. The admin role, on the other hand, had access to user management, product creation, and system configurations.

Endpoints: 

Privilege Escaltion:

1. Admin
2. Finance

• /graphql

• /graphql.json

• Custom aliases such as /ggql

My role: finance (using a test account). (Privilege Escalation on admin )

Step-by-Step Exploitation

Step 1: GraphQL Endpoint Discovery

First, I identified the GraphQL endpoints using common paths:

• /graphql returned a working GraphQL interface

• Using tools like Postman and InQL, I discovered that introspection was enabled

I downloaded the entire schema and noted down all queries and mutations.

Step 2: Sensitive Mutation Discovery

One mutation drew my attention:

mutation CreateProduct($id: String!, $name: String!) {
  createProduct(id: $id, name: $name) {
    id
    name
    createdBy
  }
}

This was clearly meant for the admin role. It allowed the creation of a product in the system.

Step 3: Capture an Admin Request (Simulated)

Using a test admin account, I observed the request sent for creating a product. It included:

• Authorization: Bearer adminToken

• GraphQL mutation with product ID and name

Step 4: Replace Admin Token with Finance Token

I replaced the admin token with a valid finance user token and replayed the exact same mutation.

To my surprise, the request was successful.

Why did this happen? The backend didn’t validate if the user role matched the operation being performed. The server simply checked if the token was valid, not if the token belonged to a user with the correct privileges.

Real-World Impact of the Exploit

This vulnerability had serious implications:

• The finance user could create products without proper authorization.

• They could potentially access audit logs, admin reports, and user data.

• In an extended scenario, this could be chained with other vulnerabilities to gain full system compromise.

This is not a theoretical issue. Many real-world applications using GraphQL face similar issues due to:

• Missing server-side role validation

• Over-exposed GraphQL schemas

• Poorly implemented authorization layers

Root Cause Analysis : Privilege Escalation

1. Missing Role Check: The createProduct mutation lacked any server-side validation for the user’s role. It assumed the frontend would hide or restrict access.

2. Overuse of Trust in JWTs: While the JWT tokens were valid, the claims within them weren’t checked during sensitive operations. For example, role=finance should have triggered a denial response.

3. Exposed Introspection Schema: This allowed discovery of mutations that shouldn’t have been publicly visible.

Mitigation Strategies

1. Implement Strong Role-Based Access Control (RBAC)

Every query and mutation must validate the user’s role before processing.

if (user.role !== 'admin') {
  throw new Error('Unauthorized');
}

Don’t rely solely on frontend validation.

2. Disable Introspection in Production

Use middleware to block schema introspection in production environments.

const { graphqlHTTP } = require('express-graphql');
graphqlHTTP({
  schema,
  graphiql: false,
  customFormatErrorFn: () => null,
});

3. Enforce Field-Level Authorization

Instead of protecting only at the endpoint or mutation level, ensure that each field in your schema is protected.

4. Audit and Monitor

Set up logging and monitoring on sensitive queries. Alert on:

• Role misuse

• Excessive replayed queries

• Field access patterns

5. Use Allowlists

Only allow access to a predefined list of queries or mutations based on roles. Tools like Hasura or custom middleware can help enforce this.

Key Lessons for Bug Bounty Hunters

• Always inspect GraphQL introspection results for overlooked fields and mutations.

• Try swapping valid tokens across roles to test access control flaws and hunt of Privilege Escalation

• Just because a mutation is hidden on the frontend doesn’t mean it can’t be accessed.

• Combine escalation with IDOR or insecure object references to expand the impact.

Final Thoughts

This bug was simple but devastating. It highlights why GraphQL applications need strict backend validation and continuous security review. Developers often rely on frontend controls or incomplete middleware, assuming it will prevent abuse. However, security must always be enforced server-side.

As a bug bounty hunter, your job is to think creatively. Ask questions like:

• What if I change the token?

• What if I access the mutation directly?

• What if I modify hidden fields?

GraphQL gives attackers power. Make sure your security matches that power.

External Links :

• Graphql

• Owasp-Graphql

• Portswigger-Burp

• Privilege Escalation

Final Thoughts: Keep Hunting, Keep Learning

This was one of my earliest critical bug bounty finds and taught me that Graphql APIs are one of the most vulnerable attack surfaces today. With tools like Swagger, Postman, and Burp Suite at your disposal, you don’t need to brute force—just observe and test logically.

🔍 Graphql API is more than headers and tokens—it’s about understanding how developers structure access and how attackers think. 

If you found this write-up helpful, feel free to connect with me on LinkedIn or follow my work on Twitter.

Until next time, stay curious and stay secure! 🔐