Security Cipher
Home Blog About Us
Resources β–Ό
πŸ—ΊοΈ Penetration Testing Roadmap 🌐 Web Application Security Checklist πŸ€– OWASP Top 10 for LLM Applications 🧠 LLM AI Security Checklist πŸ› οΈ Security Tools 🎯 Penetration Testing Tricks πŸ“„ Secure Code Explain πŸ“– Vulnerability Explain ☁️ AWS Cloud Security Checklist
My Resume
Contact Us
← Security Tools View on GitHub

requests-racer

Small Python library that makes it easy to exploit race conditions in web apps with Requests.

Requests-Racer

Requests-Racer is a small Python library that lets you use the Requests library to submit multiple requests that will be processed by their destination servers at approximately the same time, even if the requests have different destinations or have payloads of different sizes. This can be helpful for detecting and exploiting race condition vulnerabilities in web applications. (For more information, see motivation.md.)

Disclaimer

Requests (and urllib3, which Requests uses internally) were never intended to allow you to do somehting like this. Requests-Racer is therefore forced to resort to some fairly terrible hacks to get fine-grained control over how requests are submitted.

These hacks include messing with the private state of some urllib3 objects, so an urllib3 update that is backwards-compatible w.r.t. its public API might still break Requests-Racer. Therefore, I recommend using Requests-Racer in a virtualenv and installing it before Requests or urllib3, so that a known-compatible version of these libraries is pulled as a dependancy.

Installation

To use Requests-Racer, you will need Python 3.5 or later. First, create and activate a Python virtual environment:

python3 -m venv env
source env/bin/activate

Then download a copy of the library and install it:

git clone https://github.com/nccgroup/requests-racer.git
cd requests-racer
python setup.py install

Usage

Requests-Racer works by providing an alternative Transport Adapter for Requests called SynchronizedAdapter. It will collect all requests that you make through it and finish them only when the finish_all() method is called:

import requests
from requests_racer import SynchronizedAdapter

s = requests.Session()
sync = SynchronizedAdapter()
s.mount('http://', sync)
s.mount('https://', sync)

resp1 = s.get('http://example.com/a', params={'hello': 'world'})
resp2 = s.post('https://example.net/b', data={'one': 'two'})

# at this point, the requests have been started but not finished.
# resp1 and resp2 should *not* be used.

sync.finish_all()

print(resp1.status_code)
print(resp2.text)

To make your code simpler, you can also use SynchronizedSession, which is just a requests.Session object that automatically mounts a SynchronizedAdapter for HTTP[S] and proxies the finish_all() method, so the code above can be rewritten as follows:

from requests_racer import SynchronizedSession

s = SynchronizedSession()

resp1 = s.get('http://example.com/a', params={'hello': 'world'})
resp2 = s.post('https://example.net/b', data={'one': 'two'})

# at this point, the requests have been started but not finished.
# resp1 and resp2 should *not* be used.

s.finish_all()

print(resp1.status_code)
print(resp2.text)

Here are some caveats to keep in mind and fancier things you can do:

  • SynchronizedAdapter is not thread-safe.
  • Requests made through a SynchronizedAdapter will not update the session object (e.g., cookies from Set-Cookie headers will not be added to the session's cookie jar).
  • Redirects might not be followed, try to avoid them.
  • If an exception occurs while starting a request, it will be re-raised exactly like with regular requests. However, if one occurs while finishing a request, it will not be re-raised. Instead, the response to the request will have status code 999 and contain a traceback in its .text attribute.
  • SynchronizedSession.from_regular_session constructs a SynchronizedSession from a requests.Session instance. This is helpful if you need to make some simple requests to e.g. log into a service and get a session cookie that you'll need for the synchronized requests.
  • SynchronizedAdapter and SynchronizedSession accept an optional parameter called num_threads, which gives the maximum number of threads the adapter will use. If not specified, the adapter will use one thread per request.
  • finish_all() accepts an optional parameter called timeout, which gives the maximum amount of time (in seconds) that the adapter will wait for a thread to finish.

See benchmark/ for notes on performance.

License

Copyright (C) 2019 Aleksejs Popovs, NCC Group

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see https://www.gnu.org/licenses/.

Press Escape to close the search panel.

Donate

Buy me a Coffee

Penetration Testing Services - Fiverr

Buy me a Coffee

Penetration Testing Services

penetration Testing Services

Web Application Security Quiz

Web Application Security Quiz

Daily Bug Bounty Writeups - Twitter

Daily Bug Bounty Writeups

Download our Latest Android Application

Guide for Penetration Testing

Daily Bug Bounty Writeups - Telegram

Daily Bug Bounty Writeups

Author

Piyush
Senior Product Security Engineer

Ethical Hacker || Penetration Tester || Gamer || Blogger || Application Security Engineer

READ ARTICLE

Donate

Buy me a Coffee

Recent Posts

  • Web Cache Poisoning in 2026: A Practical Playbook (One Request, Every Victim)
    Web Cache Poisoning in 2026: A Practical Playbook (One Request, Every Victim)
    July 19, 2026/
    0 Comments
  • Is AI Killing Bug Bounty? What the 2026 CVE Flood Really Means for Hunters
    Is AI Killing Bug Bounty? What the 2026 CVE Flood Really Means for Hunters
    July 17, 2026/
    0 Comments
  • AI Pentest Tools in 2026: What Actually Works (T3MP3ST, PentestGPT, Caido and More)
    AI Pentest Tools in 2026: What Actually Works (T3MP3ST, PentestGPT, Caido and More)
    July 16, 2026/
    0 Comments

Follow Us

SecurityCipher

Practical security guides, vulnerability deep-dives, and hands-on resources for bug bounty hunters and penetration testers.

Useful Links

  • Blogs
  • About
  • Contact

Recent Post

  • Web Cache Poisoning in 2026: A Practical Playbook (One Request, Every Victim)
  • Is AI Killing Bug Bounty? What the 2026 CVE Flood Really Means for Hunters
  • AI Pentest Tools in 2026: What Actually Works (T3MP3ST, PentestGPT, Caido and More)
Β© 2026 SecurityCipher. All rights reserved. Privacy Policies Β· Terms & Conditions