Change one number in the URL. See someone else's invoice.
That's an IDOR, and it's still one of the most common bugs we find in API pentests.
How it happens:
GET /api/invoices/1042 → your invoice
GET /api/invoices/1043 → someone else's invoice
The server checks that you're logged in. It never checks that invoice 1043 belongs to you.
Where to look:
• IDs in URLs, JSON bodies and headers
• "Export", "download" and "share" endpoints
• Mobile app APIs (often less tested than web)
• Old API versions like /v1/ still live next to /v2/
The fix: check ownership on every request, on the server. Not in the UI.
Bookmark this for your next code review.
@pashov Hiding the code isn't security. It slows down the people who would report bugs, not the ones who would exploit them. Unverified bytecode still gets decompiled.
A small audit beats no audit.
@IntCyberDigest If the charges hold up, the lesson for buyers is simple: ask any security vendor to show their method and evidence, not just promises.
"We can decrypt it, no ransom needed" should always come with proof.
@pentest_swissky Great map, bookmarking.
In real engagements the "boring" paths still do most of the damage: Kerberoastable service accounts, over-permissive ACLs, misconfigured ADCS templates.
@Jhaddix The supply chain angle is underrated. Teams lock down the prompt and forget the model server, vector DB and inference cache sitting on the same internal network.
SSRF into an inference endpoint is the new SSRF into cloud metadata. Looking forward to that lab.
@infinitelogins Great breakdown. Layered checks only help if each layer validates the same thing.
When the gateway, the backend and a trusted-client header each assume the others did the real check, you get exactly this.
@sunilyedla2 2FA protects the login page, not the account.
Any path that issues credentials (API keys, app passwords, OAuth tokens) before the second factor is done is a full bypass. Nice find.
@navid_rebian Most underrated skill in security: understanding how the business makes money.
Scanners know payloads. They don't know your refund policy. That's why logic bugs are still where manual testing wins.
@codewithkhalil Neither is more secure by default.
Sessions are easier to revoke and harder to misuse. JWTs scale well but come with classic mistakes: no expiry, alg confusion, weak signing secrets, sensitive data in the payload.
Pick for the use case, then implement it properly.
Short-lived access tokens (5–15 min) + refresh tokens tracked server-side.
On compromise: revoke the refresh token, add the access token's jti to a denylist (Redis, TTL = remaining lifetime), and bump a per-user token version so every older token fails.
"Stateless" was always a trade-off, not a rule.
@NahamSec The dupe pain is real. Upside: you now own a working chain for that sink pattern, and it will pay on the next target.
What finally cracked it, the filter or the context?
@Wakedxy1 Classic custom-module trap. sudo() with no ownership check is the Odoo version of "the framework handles auth".
Good call reporting the metadata-only leak too. Filenames and IDs alone often hand an attacker the next target.
@h4x0r_dz Fair point. Another path for people starting now: build skills on labs and bounty programs, then move into paid pentests / VAPT.
Scope is agreed, pay is fixed, and you get to test internal apps no public program will ever show you.
@tabaahi_ Impressive setup. Curious how it handles business logic bugs: a refund flow that can be replayed, or a role check that only breaks on step 3 of a workflow.
Those tend to be the ones automation struggles with. Do you hand-verify before submitting?
@mainteemoforfun Congrats, well deserved. Interesting that AI surfaced the lead. In our experience the model finds the thread and the human proves the impact.
How much manual work did it take to turn it into a valid PoC?
"We have HTTPS, so we're secure."
HTTPS protects data while it travels. That's it.
It does NOT stop:
• SQL injection
• Broken access control
• Stolen or weak passwords
• Leaked API keys in your JS files
• Business logic abuse (coupons, refunds, limits)
The padlock means the connection is private. It says nothing about what happens once the attacker is talking to your app.
What security myth do you hear most from clients? Reply below.
Why each one fails:
1. Attackers don't use your UI. They call the API directly.
2. Burp or curl skips your JavaScript entirely.
3. URLs leak via logs, referrers, browser history and JS files.
4. Unguessable IDs ≠ authorisation. IDs leak, and then anyone can use them.
5. A standard JWT is signed, not encrypted. Anyone can decode the payload.
6. Attackers rotate IPs cheaply.
7. HTTPS protects data in transit. It does nothing for broken logic.
8. DevTools exists.
9. Base64 is encoding. Anyone can reverse it in a second.
10. "Internal" lasts until one SSRF or one compromised laptop.
Need a human-led pentest? https://t.co/tVq8foOgkC
Follow @pocforge for more.
Things developers think are security controls, but aren't:
1. Hiding the admin button in the UI
2. Client-side validation only
3. "Nobody will guess that URL"
4. Using UUIDs instead of real access checks
5. Thinking a JWT is encrypted
6. Rate limiting only by IP
7. "We use HTTPS, so we're secure"
8. Disabling right-click
9. Base64 as "encryption"
10. "It's an internal API, it's not exposed"
The fix is always the same: enforce it on the server. Every time.
Which one have you seen in production? 👇
Bookmark this and send it to your dev team 🔖