Building InternTrack: Lessons from Shipping a Full CRM in 2 Weeks, and How I Used Google Dorking to Find Exposed Admin Panels (Ethically)

InternTrack started as a simple idea: job hunting generates a mess of spreadsheets, email threads, and sticky notes, and I wanted a single place to track applications, interviews, deadlines, and offers like a real CRM. I gave myself two weeks to ship a working version, end to end, on the MERN stack (MongoDB, Express, React, Node.js). This post covers what that sprint actually looked like, and — in the second half — an ethical, high-level look at Google Dorking, a security-research technique I explored while thinking about how to keep InternTrack's own admin surface from being accidentally exposed.

Designing InternTrack's Architecture

The core of InternTrack is a personal CRM: applications move through stages (Applied → Interviewing → Offer → Closed) on a drag-and-drop Kanban board, with an analytics dashboard summarizing progress across all of them. Getting the board to feel responsive without a heavyweight drag-and-drop library was one of the more interesting front-end problems — it meant being deliberate about where state lived on the React side versus what the backend needed to persist on every card move.

On the backend, Express and MongoDB handle the data layer, with routes scoped per-user so applications, deadlines, and notes never leak across accounts. Authentication uses JWT (JSON Web Tokens) — a short-lived access token for API calls, paired with a longer-lived refresh flow so users aren't forced to log in again every time a token expires. Getting refresh-token handling right (rotating them safely, invalidating old ones, not leaving a window where a stale token still works) was one of the parts I spent the most time getting comfortable with, since auth bugs are the kind that don't show up until they're a real problem.

What Two Weeks Actually Teaches You

• Scope ruthlessly. The first version of InternTrack didn't have the analytics dashboard — it was added once the core tracking flow (add application → move through stages → mark outcome) was solid. Shipping the boring, essential path first made the deadline realistic.
• Auth is not a "nice to have" you bolt on later. Building JWT auth in from day one — rather than retrofitting it — avoided a rewrite of every route once real user data existed.
• A Kanban board is mostly state management, not drag-and-drop code. Once the data model for "which stage is this application in, and in what order relative to its siblings" was right, the UI interactions became straightforward.

A Detour Into Ethical Security Research: Google Dorking

While thinking about what it would mean for InternTrack (or any side project) to accidentally expose an admin panel to the public internet, I spent time learning about Google Dorking — the practice of using advanced search-engine operators (like site:, intitle:, or inurl:) to surface pages that a search engine has indexed but that were never meant to be publicly discoverable. It's a well-known technique in the security-research and OSINT (open-source intelligence) community, and understanding it from a defensive angle is genuinely useful for any developer shipping something public-facing.

Why Exposed Admin Panels Happen

Most exposed admin panels aren't the result of some clever attack — they're the result of ordinary oversights: an admin route that was never protected behind authentication during early development and simply never got locked down before deployment, a staging environment left publicly reachable, or default framework routes (like a database admin UI) left at predictable paths with default credentials. Search engines crawl and index whatever is publicly reachable, which means a forgotten `/admin` route can end up searchable without anyone "hacking" anything at all.

Responsible Disclosure

If a security researcher (or a curious developer) comes across something that looks like an exposed admin panel or sensitive endpoint that isn't theirs, the responsible path is responsible disclosure: don't attempt to log in, modify data, or explore further. Instead, look for the organization's published security contact (a security.txt file, a security page, or a support email) and report what was found, when, and how it was discovered — without including anything that could itself be misused. Most organizations have a process for this precisely because they'd rather hear about it from a well-intentioned researcher than from someone with worse intentions.

What Developers Should Do to Prevent This

• Never rely on an unlisted/obscure URL as your only protection — treat every admin or internal route as if it will be found, and put real authentication in front of it.
• Keep staging and development environments off the public internet, or at minimum behind authentication, not just "not linked from anywhere."
• Change default credentials on any framework or tool that ships with them, immediately.
• Use a robots.txt as a courtesy signal to well-behaved crawlers, but never as a security control — it does nothing to stop a determined search or a misbehaving bot.
• Periodically search your own domain the way an outsider would, so you find your own mistakes before someone else does.

Bringing It Back to InternTrack

The direct takeaway I applied to InternTrack: every route that touches user data or admin-level actions sits behind the same JWT authentication used for the rest of the app — there's no "temporary" unauthenticated admin route left over from development. It's a small thing, but it's exactly the kind of small thing that Google Dorking research keeps reminding me matters.