From software application designer to newbie cyberpunk– what I discovered wordlists, concealed endpoints, and why unlinked does not indicate undetectable.
I’m brand-new to cybersecurity. My background remains in software application growth with JavaScript, yet I lately began questioning: just how do attackers actually see my code and APIs from the outside?
To explore this, I jumped into TryHackMe and took my very first lab. The circumstance was a straightforward “financial institution” website, and the objective was to brute-force covert directory sites utilizing a tool called dirb By discovering the appropriate covert pages, I eventually handled to include cash to my checking account inside the laboratory. It was basic, but truthfully, it felt like magic the first time I saw it function. At the very same time, it was a wake-up phone call, also small oversights in development can develop openings that attackers can utilize.
This message is my reflection: what I learned technically, what surprised me as a developer, and exactly how this changed the way I consider safety.
What I Learned
The Device: dirb
At first, I thought: how can a tool just “find” concealed stuff? But once I utilized dirb , it clicked.
dirb is primarily a presuming equipment. It takes a wordlist (a huge text documents loaded with feasible directory or file names like admin, uploads, backup.zip) and tries them one by one against the server. For each guess, it sends an HTTP obtain request and checks what comes back:
- 200 OKAY → endpoint exists
- 403 Not allowed → endpoint exists, yet I’m not admitted
- 404 Not Found → nothing there
So it doesn’t magically understand anything, it simply brute-forces actually quick. And if the server responds with something aside from 404, that’s an idea.
The Principle: Hidden Endpoints
This is where it truly gotten in touch with my backend experience. I have actually developed APIs like/ api/users and/ api/login, and in my head, those were the only endpoints that “mattered” because they were the ones wired to the frontend.
But after running dirb, I realized something important: even if I don’t link to an endpoint, if it’s released, it’s still visible. That includes points like/ test,/ backup, or/ old, the kind of things programmers commonly leave throughout testing or release. I used to assume unlinked = risk-free. Now I see unlinked = still noticeable if a person goes looking.
The Larger Image
This entire exercise instructed me that reconnaissance is just like rattling doorknobs on a structure– you’re not within yet, however you’re mapping what exists.
When I opened the common.txt wordlist that includes dirb, I quickly got it. It’s essentially simply a checklist of names. The tool checks them individually, and if the web server replies with 200 OK (or even 403, then something is there. Straightforward, yet effective.
The lesson for me: scanning is only as strong as the wordlist That’s why experts utilize big, well-curated collections like SecLists — because the better your hunches, the even more doors you’ll find. It was virtually funny to realize: often hacking isn’t regarding brilliant, it’s about perseverance and using the appropriate listing of names.
Self-Reflection
This exercise challenged the method I used to think about my own backend code. I presumed that if an endpoint had not been connected to the frontend, it was generally hidden. My reasoning originated from exactly how I typically deploy applications: the backend and frontend are organized separately, and the frontend calls the backend URL that I take into a env documents. In my head, this felt like security, virtually like the API link was personal. Today I comprehend that once the backend is released on the web, it’s still obtainable to any person, not simply my frontend. If the frontend can send out demands to it, then so can an assailant.
That made me think in a different way about “surprise” or “covered” endpoints. Some designers try to conceal paths behind weird or hash-looking paths, but that’s simply safety through obscurity. If an endpoint is released and does not have correct verification or gain access to control, a person who discovers it can still utilize it. So the real inquiry is: just how do I make certain that even if an assaulter finds my endpoints, they can not in fact exploit them?
I do not have all the responses yet, but this reflection is pressing me toward brand-new concerns. Should I implement solid session symbols or API tricks on every route? Should I be more stringent about cleaning up old endpoints and never leaving back-up documents in manufacturing? Just how would I also observe if a person is brute-forcing my site with a device like dirb — via logs, price restrictions, or invasion informs? My next interest is: beyond just locating the “doors,” how can I as a programmer design my system so those doors are harder, or ideally difficult, to break open?
Some directing concerns I’m asking myself currently are:
- If someone discovers/ api/admin, exactly how do I guarantee only real admins can access it?
- What takes place if I unintentionally leave/ backup.zip in manufacturing– what habits or processes would certainly stop that from occurring?
- Even if one endpoint is subjected, what extra defenses (symbols, validation, logging) could minimize the damages?
- If somebody is brute-forcing my site with a tool like dirb, just how would I even notice– with logs, rate limits, alerts?
Last Idea
What shocked me most is just how simple the concept is. Attackers do not require advanced methods to begin– even a simple text data of usual names (a wordlist) can expose covert doors. Running dirb showed me simply exactly how simple it is to discover them. As a developer, that alters exactly how I believe: the task isn’t just writing endpoints, it’s also making sure I’m not leaving doors open up that I never implied to.
Discovering Products and References
- TryHackMe : Brute Force Directory module
- Wordlists: SecLists GitHub job
- Devices: dirb
- HTTP basics: Status codes (200, 403, 404