Before we offer penetration testing to clients, we test ourselves.
This is the full story of how we attacked our own website — securenep.com — from the outside, found real vulnerabilities, and fixed every one of them. No theory. No guessing. Real findings, real fixes, real proof.
If you own a website in Nepal and you've never had a security audit, this post is for you.
#WHAT IS PENETRATION TESTING?
Penetration testing means attacking your own system the way a real hacker would, before a real hacker does.
Most website owners think: "I have a password. I'm safe."
They are wrong.
Passwords are one layer. A real attack has dozens of entry points — your contact form, your API, your login page, your error messages, your server headers. Every one of these is a door. Our job is to find the ones that are unlocked.
#PHASE 1 — RECONNAISSANCE: LEARN BEFORE YOU TOUCH
The first rule of hacking: gather information without triggering any alerts.
We ran one command:
curl -IL https://www.securenep.com
From the response headers alone, we learned:
The server is Vercel
The backend is Supabase
Which security protections were active — and which were missing
We also ran a WHOIS lookup to see what a hacker could learn about our domain registration, and checked our JavaScript bundle in the browser to see if any secret credentials were accidentally exposed to the public.
What this means for business owners: A hacker spends days studying your website before touching it. By the time they attack, they already know your tech stack, your hosting provider, and your weaknesses.
#PHASE 2 — SCANNING: FIND EVERY ENTRY POINT
Next we mapped every door on the website.
Using a tool called ffuf, we tested 4,614 possible hidden URLs automatically. We found that all sensitive routes were properly protected — but the process revealed which API endpoints existed.
#THE CONTACT FORM ATTACK
We bypassed the browser form entirely and sent raw requests directly to our server:
curl -X POST https://www.securenep.com/api/contact \ -H "Content-Type: application/json" \ -d '{"name":"Test","email":"test@test.com","subject":"HACKED","message":"test"}'
Finding #1: The server accepted any value for the service field — even "HACKED". The dropdown on the website meant nothing. The server had to validate independently.
Finding #2 and #3: When we submitted <script>alert(1)</script> as a name or message, the server stored it in the database without sanitization. This is Stored XSS — a classic attack that can give hackers control of an admin browser.
Finding #4 — The Most Serious: Our blog posts API was completely open to the public with no authentication. Anyone with a terminal could run:
curl https://www.securenep.com/api/posts
And receive our entire private database. No password. No token. Nothing.
#PHASE 3 — EXPLOITATION: TEST THE LOGIN
We attacked the admin login page from multiple angles.
Brute Force Testing: We automated 50 login attempts in a loop. Supabase protection kicked in at attempt 35. We added our own rate limiting layer.
Session Analysis: After logging in, we found the cookie lacked the HttpOnly flag. This is a known Supabase limitation. We documented it as accepted risk since our XSS vulnerabilities had been fixed.
Route Protection: We tested whether an attacker could access admin pages by typing the URL directly without logging in. The answer was yes, initially. We fixed this with server-side middleware.
PHASE 4 — POST-EXPLOITATION: WHAT CAN AN ATTACKER DO ONCE INSIDE?
We tested every function in the admin panel:
Can they inject malicious code through the post editor? No — content is rendered as plain text
Can they access locked content without a key? No — server validates before sending data
Can they bypass the secret key system? No — all bypass attempts rejected
Is there a privilege escalation path? No — admin panel only manages posts
#PHASE 5 — REPORTING: DOCUMENT EVERYTHING
Our own audit produced 9 findings. All were documented, prioritized, and resolved.
#WHAT WE FOUND AND FIXED
F-01 | Input validation bypass — service field | Medium | Fixed
F-02 | Stored XSS — message field | Medium | Fixed
F-03 | Stored XSS — name field | Medium | Fixed
F-04 | Broken access control — posts API | High | Fixed
F-05 | Weak brute force protection | Medium | Accepted Risk
F-06 | Session cookie without HttpOnly | Medium | Accepted Risk
F-07 | CORS wildcard on admin page | Low | Fixed
F-08 | Supabase credentials in JS bundle | Medium | Accepted Risk
F-09 | CSP unsafe-eval in production | Low | Fixed
#TOOLS WE USED
curl — Manual HTTP request testing nikto — Automated vulnerability scanning ffuf — Endpoint discovery and fuzzing nmap — Network and port scanning whois — Domain registration intelligence Browser DevTools — JS bundle analysis, session inspection
#THE LESSON
Security is not a product you buy once. It is a process you repeat continuously.
The difference between a secure website and an insecure one is not always technical complexity. Sometimes it is one missing line of code — like the authentication check we forgot on our posts API.
We found it before anyone else did. That is the point of penetration testing.
#IS YOUR WEBSITE VULNERABLE?
Most Nepali businesses have never had a security audit. Many are running on shared hosting with default configurations, outdated plugins, and no monitoring.
Contact us at hello@securenep.com or through the contact form at securenep.com.
SecureNep — Securing Digital Nepal Pokhara, Nepal