I recently passed the eJPT (eLearnSecurity Junior Penetration Tester). I didn't take it to pivot into security — I took it to become a better backend engineer. This is a short writeup of what actually changed in how I think about the systems I build, now that I've spent time attacking them instead of shipping them.
eJPT is an entry-level, hands-on certification. It covers networking fundamentals, host and service enumeration, web application attacks, and basic exploitation. None of it is exotic. That's exactly what made it useful — the gap between "I know what SQL injection is" and "I have actually exploited one in a lab" turned out to be bigger than I expected, and closing it changed how I read my own code.
Zoom
1. Enumeration changed how I think about attack surface
A large part of eJPT is just enumeration: finding out what's actually running, on what ports, with what versions, and what's exposed to whom. Tools like Nmap and simple banner grabbing do most of the early work.
The carryover to engineering is direct. When I design a service now, I think about it the way an attacker doing recon would see it:
- What does this service expose that it doesn't need to?
- What information leaks in error messages, headers, or stack traces?
- What's reachable from the public internet versus the internal network, and is that boundary actually enforced or just assumed?
A lot of backend security advice talks about "minimizing attack surface" as an abstract principle. Enumeration labs make it concrete — you watch how quickly an open port, a verbose banner, or a debug endpoint turns into a lead.
2. Web app attacks made OWASP Top 10 stop being a checklist
I already knew the OWASP Top 10 the way most engineers do: a list to glance at during code review. eJPT's web application modules — SQL injection, XSS, CSRF, broken authentication, insecure direct object references — forced me to actually exploit each one in a lab environment.
A few things stuck:
- SQL injection stopped being "use parameterized queries" as a rule I follow and became a rule I understand. Watching a single unescaped input turn into full data exfiltration makes "why" obvious in a way documentation doesn't.
- IDOR (insecure direct object references) was the one that mapped most directly onto real backend work. It's just object-level authorization — exactly the "verify the caller is authorized for this specific object, not just logged in" problem that shows up in API design all the time. Exploiting it a few times made me far more suspicious of any endpoint that takes an ID straight from the client.
- CSRF and session handling made the distinction between authentication and authorization, and between a valid session and a legitimate request, much more concrete than reading about tokens and cookies in isolation.
None of this is new information for a backend engineer. What changes is instinct — you start reading your own endpoints the way an attacker reads them, not the way the spec describes them.
3. Linux fundamentals and privilege escalation reinforced "least privilege"
eJPT spends real time on Linux host assessment: file permissions, SUID binaries, cron jobs, service misconfigurations, and privilege escalation paths. It's a reminder that most privilege escalation isn't clever — it's a misconfigured permission, an overly broad sudo rule, or a service running as root that didn't need to.
This connects directly to how I think about deployment now:
- Services running with more privileges than they need are a liability, not a convenience.
- File and directory permissions on servers and in containers deserve the same scrutiny as application-level access control.
- "It's an internal tool, it doesn't need hardening" is the same assumption that shows up in almost every privilege escalation lab.
4. Exploitation made input validation feel non-optional
Working through basic exploitation with tools like Metasploit — even at an entry level — makes one thing hard to unsee: unvalidated input isn't a theoretical risk, it's a direct path to code execution, data access, or lateral movement, depending on where it lands.
As a backend engineer, this reframes a few habits:
- Validating and sanitizing input stops being boilerplate and starts being the actual boundary between "my application" and "whatever the attacker wants to run."
- Trusting data from any boundary — user input, third-party APIs, message queues, even internal services — is worth questioning by default, not by exception.
5. Report writing was a reminder that security is a communication problem too
eJPT, like most pentest-oriented certifications, expects you to document findings clearly: what was found, how it was exploited, what the impact is, and how to fix it. It's a small part of the exam, but it mirrors something backend engineers already do — writing a clear incident postmortem or an architecture decision record.
The overlap is useful: a vulnerability report and a postmortem both need to separate what happened, why it matters, and what changes as a result — without burying the fix under unnecessary detail.
What I'd actually recommend to other software engineers
You don't need eJPT to become a better engineer, and this isn't a certification-collecting pitch. But if you're already comfortable reading OWASP-style advice and want it to actually change your instincts, hands-on practice closes a gap that reading doesn't:
- Try a few boxes on TryHackMe or HackTheBox before committing to a certification — enough to see if hands-on exploitation changes how you think, the way it did for me.
- Focus on the web application and enumeration modules first if your goal is backend engineering — they map most directly onto API design and object-level authorization.
- Don't skip the Linux and networking fundamentals. They're the least "exciting" part and the most directly useful for anyone who deploys or operates services.
Learning resources
- eLearnSecurity eJPT — official certification page and syllabus.
- OWASP Top 10 — the vulnerability categories most relevant to backend engineers.
- OWASP Cheat Sheet Series — practical mitigation guidance for the issues eJPT covers in practice.
- TryHackMe — guided, beginner-friendly hands-on labs.
- HackTheBox — less guided, more realistic hands-on labs.
Final thought
eJPT didn't teach me anything I couldn't have read about elsewhere. What it did was move a set of security principles from "things I know" to "things I've done" — and that shift is what actually changes how I write and review backend code day to day.