Notes from the edge of trust boundaries.
Write-ups on the bug classes I hunt for a living β request forgery, broken authorization, memory safety, on-chain logic, injection in build pipelines β the method that keeps the conclusions honest, and guidance for the teams who have to defend against all of it.
Latest dispatch
All field notes
Work with me
Audit Β· Penetration test Β· AdvisoryFind it before they do
A deep, white-box read of your architecture and code for the vulnerability classes written up on this blog β authorization, request forgery, injection, tenancy, secret handling.
- Threat model of your real attack surface
- Source & architecture review
- Auth, multi-tenancy & secrets deep-dive
Prove the impact
Black- or grey-box testing of web apps, APIs, and cloud infrastructure. Real exploitation, honest severity β the ceiling I prove is the ceiling I report, with a witness for every claim.
- Web, API & cloud infrastructure
- Working proof-of-concept, no scare tactics
- Remediation guidance & a re-test
Security on tap
An ongoing partnership for teams without a full security function. The For teams guidance on this blog, applied continuously to your codebase and decisions.
- Security review on risky pull requests
- Threat modeling for new features
- Incident support when it matters
Have a system you want tested?
Independent, coordinated, and straight about impact. Tell me what you're building and what keeps you up at night.
About
Marouane DahmaniMy first hack, at eight, was setting the family Windows 95 clock back a few days so the game trials would reset β forever.
I grew up in a modest household where buying software wasn't really on the menu, but the trial timers had a weakness and I had a system clock and an abundance of free time. I reasoned, with the airtight logic of an eight-year-old, that the game had simply never specified which year it was. It did not argue back. I like to think of it as my first responsible disclosure β I just never got around to filing the report.
It worked for years before I understood why, and by then the hook was set. Not the free games β the gap. The distance between how a system is supposed to behave and how it actually does. Hand me a rule and I want to know exactly where it stops being true. I've been chasing that gap ever since.
I took the scenic route into it. Two master's degrees β one in mathematics, one in data engineering β which taught me to reason precisely and to distrust any result a single instrument confirms. That training runs through everything on this blog: prove the primitive, control the baseline, never conclude without a witness.
But the pull was always toward the thing I actually love. Rather than settle into a data career, I chose the work that keeps me curious β crypto trading on one side, ethical hacking on the other. Two disciplines that reward the same instincts: patience, adversarial thinking, and a stubborn refusal to accept a comfortable story over a proven one.
What I chase now is the improbable challenge β the bug everyone assumed wasn't there, the boundary that was supposed to hold. This blog is where the security half of that gets written down: the classes, the reasoning, and the traps, so the next person doesn't have to relearn them the hard way.
How I work β disclosure ethics
Test only what I'm authorized to test. Prove impact without harming data or users. Never conclude from a single instrument. Report through the proper channel, and let the fix land before anyone writes the story. Everything published here is educational and deliberately abstract β no live targets, no unresolved reports, no client names, and no code that mirrors any real system. The point is the shape of a bug, not who had it.