I wanted to understand Payments better ... and learned about HAR files.

I started following up on my challenge of learning more about how payments in Web2 work: I set up my account, my sandbox, and a simple checkout flow. I went through the flow once, and it
worked. What pulled me to this project was a desire to learn more about payments, since they are everywhere — but I also wanted to know which data was transmitted where and what implications
this had for privacy.

I started looking at the requests in this flow: 521 requests visible in the network tab of the developer tools, and 129 hCaptcha requests. I didn't know what hCaptcha requests were, so I asked Claude, and that is how I found out. hCaptcha is a mechanism that Stripe uses to detect fraud. It sends events like when you move the mouse or interact with a field, to analyze whether your patterns are human or potentially fraudulent.

I started looking at each request individually, but pretty soon I got bored. I couldn't imagine sitting for hour, that I don't have, examining each request at a time, So I asked Claude again whether something could be done to get information on the request patterns themselves and the data flowing between them. That is how I learned about HAR files. I am guilty of not knowing what they were until today, even having spent considerable time in engineering.

I downloaded myHAR file, and one of the first things I saw was the plain-text credit card number with CVC and expiration date. Of course, this was only a sandbox environment with Stripe's test credit card number, but I wondered how it could make me vulnerable in a real-life scenario. I felt uneasy when I saw this and also a bit scared: was this for real?

The file is local and would only cause issues if shared. As I learned, HAR files are often used to debug performance and other issues, such as authentication. You can even use them to set up
end-to-end tests with Playwright, to record the flow and requests that should be tested. Very useful — but also unsettling to see credentials in plain text: I started imagining catastrophic scenarios, just to come back to earth and think that I was probably exaggerating. I wondered if there had already
been an incident involving these files. And it turns out that in fact, yes, there was one, and a pretty serious one. In 2023, there was an Okta incident in which an employee signed into their personal Google account and stored HAR files for
debugging there. The account was compromised, and the attacker could access the HAR files and impersonate users from affected customer companies through the captured session data. So my catastrophic thinking was not that far away from reality.

Back to payments: Following Stripe's architecture, which is optimized for security, my server does not see the payment information. TLS encrypts the card data in transit, so no one intercepting the network can
read it — but the HAR file captures what the browser saw before encryption happens. Afterwards, these values get tokenized, making them useless if compromised. The real number only ever lives
in Stripe's vault. What surprised me is that the HAR file exists precisely in the window between typing the card values and Stripe tokenizing them, and can capture those values in plain text.
Tokenization doesn't eliminate the attack surface — it reduces it to a single call over TLS (Transport Layer Security).

Another interesting aspect of this architecture is that my server does not see the payment details at all: it creates a session, hands the user to Stripe's hosted page, and waits. That's why
it never sees the card. This makes it more secure, but it also means I have no visibility. If your payment success rate drops from 95% to 87% overnight, your server logs show nothing. All you
see is fewer users reaching your success page. You don't know if users are abandoning at the card form, if cards are being declined, if Stripe's fraud detection is blocking legitimate users,
or if there's a performance issue on Stripe's hosted page. All of that happens inside the session, on Stripe's infrastructure, invisible to you. To get that visibility back, you need Stripe's
dashboard, Stripe's analytics, and Stripe's support. You are dependent on their tooling to understand your own checkout.

I came to this project wanting to look at what PII data was being sent along with requests, and in doing so stumbled upon the HAR file: a debugging file that many developers don't think twice
about, but that can become a liability. Throughout this process, I used AI, not to write the text or define the angle, but to help me see patterns across 521 requests, which also helped me find context on how HAR files can be accessed and misused. I also found more about Stripe's architecture and one of the tradeoffs it makes.

What shifted for me during this finding was: First, the realization that I didn't know anything about these HAR files, then I wondered for how long they have existed, and how people were probably sharing them through Slack, JIRA tickets, handling them without so much care until this incident happened. And now I am also wondering what other small files, processes, or artifacts are sitting there without much consideration that could also be a surface for an attack?

Sources & Resources

• Using HAR files for testing with Playwright and CodeceptJS
• How to generate and analyze HAR files — Auth0
• Reddit: Do you scrub HAR files before sending them to support?
• HAR Sanitizer tool
• Introducing HAR Sanitizer: secure HAR sharing — Cloudflare
• The Okta breach — third-party incident
• Okta security advisory: HAR files
• Okta: Unauthorized access to support case management system — root cause analysis