LoganSec

⚡Building LoganSec in public.
🔎 Bug bounty, web security, recon, and tools.
🎥 Documenting the process on YouTube.

[LoganSec @LoganOpSec]

Just launched https://t.co/c4MWB2mHIf.

Nothing fancy.

Just one place for the real bug bounty journey:

→ live hunting videos
→ recon automation
→ writeup breakdowns
→ wins, dupes, N/As, and field notes
→ free JS Recon Kit coming soon

No fake wins. No guru stuff. Just building in public.
https://t.co/c4MWB2mHIf

[LoganSec @LoganOpSec]

@0xspryon ok

[LoganSec @LoganOpSec]

Just popped my first ever XSS on a real target.

It was Self-XSS, so I’m not reporting it by itself.

But the interesting part:

I opened Chrome DevTools console and ran:

window.location = "javascript:alert(1)"

And it popped.

No CSP blocking it.

Then I tested more of the BBP, and the same behavior kept working across the app.

Right now, the real question is not “can I pop alert(1)?”

The real question is:

Can this be escalated into something with actual impact?

That’s what I’m digging into now.

Small milestone, but honestly a cool one.

#bugbounty

[LoganSec @LoganOpSec]

@0xspryon Appreciate you reaching out. I intentionally kept the target/program out of the video, so I don’t want to discuss specifics publicly. The behavior was real though, even if it was marked Informative. DM me and we can compare notes at a high level.

[LoganSec @LoganOpSec]

Client-side bugs are humbling me.

I thought I understood JavaScript “enough” for bug bounty.

I didn’t.

Reading real JS, tracing browser behavior, using DevTools properly, and understanding sources/sinks is a completely different game.

That’s the skill gap I want to document.

Not pretending I’m good.

Showing the process of getting good.

More bug bounty notes:
https://t.co/WJ4OaiBgP3

#bugbounty

[LoganSec @LoganOpSec]

Day 1 of learning postMessage bugs somehow sent me back into DOM XSS fundamentals.

Did a PortSwigger Stored DOM XSS lab and learned something I somehow didn’t know:

JavaScript .replace() only replaces the first match unless you use a global regex.

So, if an app tries to “escape” HTML like this:

replace("bad char", "escaped char")

…it might only escape the first dangerous character.

That means the second one can still slip through and lead to XSS.

Tiny JavaScript behavior. Real security impact.

This is exactly why I’m trying to get better at actually understanding client-side JavaScript instead of just memorizing payloads.

#bugbounty

[LoganSec @LoganOpSec]

@rm_rf_chumy Bro that's just the road to first bounty! lol

[LoganSec @LoganOpSec]

Yeah, you’re right! thank you for the knowledge.

I realized the console test alone doesn’t prove self-XSS. It mainly shows that CSP wasn’t blocking that javascript: execution path.

For it to actually be self-XSS, I’d still need a real source → sink path inside the app where user-controlled input gets executed without manually using DevTools. Thanks for letting me know, I'm getting better at client-side bugs.

[LoganSec @LoganOpSec]

Next bug class I’m learning:

postMessage vulnerabilities.

Super niche client-side JS stuff.

But it fits perfectly with the kind of hunter I want to become:

- find interesting JS
- trace message handlers
- understand trust boundaries
- test origin validation
- look for real impact

This is where I want LoganSec going.

More technical. More raw. More focused on actually getting better.

#bugbounty

[LoganSec @LoganOpSec]

https://t.co/c4MWB2m9SH is rebuilt and live.

The goal was not to make some overbuilt “cyber portfolio.”

I wanted one clean place for:

- real bug bounty field notes
- manual recon lessons
- JS recon tooling
- weekly techniques
- Field Teams waitlist

Simple site. Clear funnel. Back to hunting.

https://t.co/c4MWB2m9SH

#bugbounty #cybersecurity

[LoganSec @LoganOpSec]

When I first started bug bounty, I thought the problem was that I didn’t know enough bugs.

So, I spent a full month grinding PortSwigger labs before I ever touched a real program.

SQLi, XSS, access control, auth bugs, logic flaws…

Then I finally opened a real target and immediately got humbled.

I had no idea where to start.

So what did I do?

I started fuzzing the homepage for random words like:

- admin
- secret
- backup
- test
- dev

And when nothing worked, I felt completely lost.

Looking back, the issue wasn’t that I didn’t know enough vulnerabilities.

The issue was that I had no recon process.

I didn’t know:

- What apps existed
- Which ones had login
- Which ones had roles
- Which ones had user-controlled data
- Which flows were actually important
- Which endpoints were worth testing
- Which assets were forgotten or less protected

I was trying to “find bugs” before I even understood the attack surface.

That’s backwards.

Beginners think:

“Once I learn more bugs, I’ll find bugs.”

But I’m starting to realize it’s more like:

“Once I understand the target better, I’ll know which bugs are actually worth testing for.”

Recon is not just collecting subdomains.

Recon is how you stop being lost.

#bugbountytips #CyberSecurity #Recon

[LoganSec @LoganOpSec]

@being__aman @Hacker0x01 Manual testing.

Pick one feature, understand the logic deeply, then ask:

“Can I do this as another user, with another role, or before/after the intended step?”

That mindset will take you further than running 50 tools with no plan.

[LoganSec @LoganOpSec]

@karthikponna19 I am a bug bounty hunter with real reports and still don’t remember

[LoganSec @LoganOpSec]

This is the type of IDOR checklist beginners actually need.

Not just “change the ID and see what happens,” but testing different object locations, request methods, encodings, batch IDs, nested JSON, and weird parameter behavior.

Most IDORs are missed because people test the obvious version once and move on.

[LoganSec @LoganOpSec]

@fr4vian This is exactly why I think bug bounty is far from dead.

It’s just getting harder to win with surface-level testing.

The hunters who can go deep on one program, understand the app, and think through weird business logic are still going to eat.

[LoganSec @LoganOpSec]

@rgjny_ I really believe reviewing the JS is super important. You can find so many hidden things in there. Which ended up leading to a bug; Congrats!

[LoganSec @LoganOpSec]

A few months ago, LoganSec was just a random idea.

Now there’s:

→ YouTube channel
→ Private email list
→ GitHub
→ LinkedIn
→ X
→ https://t.co/c4MWB2m9SH

Still early. Still not where I want it to be.

But this is starting to feel less like “content” and more like an actual cybersecurity brand being built in public.

Now I just need to keep doing the real work:

hunt bugs, document the process, and share what I learn.

#BugBounty #CyberSecurity

[LoganSec @LoganOpSec]

@Bugcrowd Or using AI, does not Validate, and submits an N/A

[LoganSec @LoganOpSec]

Most “secrets” from JS recon are garbage.

So, I’m building a script to stop wasting time.

It takes SecretFinder hits and automatically tests them against the real service APIs.

Example:

Twilio SID + token found in JS
→ test it
→ valid or invalid
→ move on fast

The goal isn’t to pretend automation finds bugs.

The goal is to remove the boring validation work so I can spend more time chasing real impact.

#bugbounty #CyberSec

[LoganSec @LoganOpSec]

I draw the line at “AI can speed up my process, but it can’t replace my judgment.”

For bug bounty, I’m fine using AI for:

- scripting
- organizing recon output
- turning messy notes into workflows
- helping me understand unfamiliar code faster

But the actual attack vector still has to come from me.

The dangerous part is when beginners let AI decide what matters. That’s how you end up with a pile of false positives and no real skill gained.