feat: draft post on intercepting http requests

diff --git a/posts/2026-05-13-how-to-intercept-http-requests.md b/posts/2026-05-13-how-to-intercept-http-requests.md
new file mode 100644 (file)
index 0000000..0687613
--- /dev/null
+++ b/posts/2026-05-13-how-to-intercept-http-requests.md
@@ -0,0 +1,70 @@
+---
+title: How to Intercept and Modify HTTP Requests
+date: Wed, 13 May 2026 11:59:57 -0500
+---
+
+This blog post comes with an accompanying YouTube video where I showcase a demo
+application and intercept its requests. Watch it here: TODO.
+
+You have a flashy HTTP API and everybody wants to talk to it. Great! But with
+great power comes great risk. All these fuckers could be sending bullshitty
+strings to your carefully (or rather, <i>not carefully</i>) crafted service.
+What's more, some shady hackers could be waiting, licking their lips and
+drooling all over, to do nasty stuff, such as modifying in-flight requests!
+
+Granted, my understanding is that tampering like this is not possible with
+encrypted protocols such as HTTPS. But alas, my security team knows better (I
+guess).
+
+So, in this post and from painful experience, I am going to show you a very
+cool tool you can use to intercept and modify requests to your APIs, so that
+you know what insidious vulnerabilities are hiding before the security guys.
+
+The tool in question is <a href="https://www.charlesproxy.com/">Charles</a>.
+
+## Installation and setup
+
+It's pretty freaking easy to set up. First, install it following the
+instructions here: https://www.charlesproxy.com/documentation/installation/.
+Then just run it!
+
+Capturing web traffic should work out of the box, but you have to configure the
+tool to allow for SSL capturing (HTTP<i>S</i>). For that, you can follow these
+instructions:
+https://www.charlesproxy.com/documentation/proxying/ssl-proxying/.
+
+You should add each hostname for which you want to enable SSL proxying in the
+configuration.
+
+## Configuring you mobile device for capturing
+
+Now, I was more interested in capturing mobile traffic from the emulator
+running on my machine. The steps are equally easy, if a little bit more
+involved.
+
+Actually no, it's dead simple. Basically, it should work out of the box. The <a
+href="https://www.charlesproxy.com/documentation/configuration/browser-and-system-configuration/">
+documentation</a> says that if you are not seeing your mobile traffic in
+Charles, you should make sure that Charles is <i>already running</i> before
+launching your simulator.
+
+Once that's done, you should be able to start intercepting requests coming from
+you emulator.
+
+## Intercepting requests (AKA Breakpoints)
+
+You can either set breakpoints at the host level or at the request level. For
+my use case, I wanted to intercept all requests going to my backend, so I
+activated breakpoints on the host.
+
+To do this, go to the TODO view, right click on your host and toggle the
+"Breakpoints" option. Then make a request and you should see execution pause a
+new window open in Charles where you can do things like aborting or canceling
+the request, allowing it through, or, in our case, modify it before sending it.
+
+You can select the option to modify the request and then alter the JSON
+payload.
+
+So that's it. I hope you found these instructions clear enough and sorry for
+not using images. I haven't gotten to decide where I would host such images
+yet.