A real-world look at why application-level security testing matters, what VAPT uncovered, and how teams can approach independent validation responsibly.
Most teams focus on adding new features or improving UX — but security often gets attention only when something goes wrong.
Our engineering group recently ran a Vulnerability Assessment and Penetration Testing (VAPT) on an ERP platform we maintain and learned first-hand how deep application-level testing changes the way you think about building secure software.
This post isn’t a product pitch — it’s a look behind the process, what the testing revealed, and why independent validation is worth the effort for any growing platform.
Why We Decided to Undergo VAPT
Like many development teams, we handle sensitive operational and financial data for our clients. While internal code reviews and automated scanners caught common issues, we wanted external verification — a true, third-party attempt to break our application.
That’s where DATA-PROVE Cybersecurity came in. Their mandate: evaluate the application’s security posture at the code and API level using the OWASP Top 10 (2021) framework — still the latest official release as of 2025.
OWASP is drafting its 2025 revision, but until finalized, the 2021 edition remains the most recognized standard for web-application testing.
One reason this kind of assessment isn’t done often by smaller teams is cost.
In the Philippines, a full-scope VAPT engagement can cost anywhere between ₱100,000 and over ₱1 million, depending on depth, assets, and number of environments tested.
It’s not a cheap process — but it’s a strategic investment. For teams managing business-critical data, the expense is often smaller than the potential loss from a breach or compliance failure.
Understanding VAPT from a Developer’s Perspective
If you’ve never gone through a full Vulnerability Assessment and Penetration Testing, here’s the quick rundown:
- A Vulnerability Assessment identifies misconfigurations and weak points in code or infrastructure.
- A Penetration Test takes those findings and tries to exploit them — safely — to measure real impact.
It’s less about “passing or failing” and more about understanding how your application behaves under pressure.
How the Testing Was Done
The assessment took place from October 31 to November 2, 2025, covering both staging and backup environments. DATA-PROVE approached the system from both authenticated and unauthenticated perspectives — simulating what a real attacker could realistically do.
They examined:
- GraphQL and API endpoints, checking for introspection or injection vulnerabilities
- Session management and cookies, validating secure timeouts and invalidation
- Authentication flows, ensuring password and 2FA logic held up
- Access control rules, verifying data isolation between user roles
These are areas that automated scanners can’t always evaluate well — especially where business logic meets session state.
Key Insights (and Humbling Moments)
The biggest takeaway wasn’t the list of findings — it was the mindset shift afterward.
Even “medium” severity issues at the application layer can expose critical logic paths if ignored.
We learned that:
- Small framework defaults (like leaving GraphQL introspection enabled) can expose internal structure.
- Session timeouts directly affect risk exposure, not just user convenience.
- Two-factor authentication isn’t a cure-all, but it’s a solid compensating control when password reuse is allowed for policy reasons.
The process gave our developers a sharper view of how attackers think — something textbooks rarely teach.
Transparency and Continuous Security
After validation, we documented our security approach publicly on our Security & Privacy page.
That page outlines controls such as:
- Encryption (in transit and at rest)
- Role-based access control
- Authentication policies and periodic vulnerability reviews
Publishing these details was a deliberate step toward accountability. Transparency helps both internal teams and clients understand that security isn’t static — it’s maintained.
Why Independent Testing Matters
For engineering leads and product owners, independent VAPT isn’t just a compliance checkbox. It’s a feedback loop that reveals how systems behave beyond assumptions.
A few takeaways for other teams:
- Treat findings as learning material, not failures.
- Include developers in debriefs — they’ll spot design-level fixes early.
- Schedule smaller, recurring reviews rather than one big annual audit.
- Share results responsibly — openness builds trust.
In our case, the experience reshaped how we plan releases and code reviews.
Security as an Ongoing Discipline
No test ends with “perfect security.”
The real success of a VAPT engagement is the culture it builds — treating security as continuous improvement, not a single milestone.
For teams building SaaS or ERP systems, the key lesson is that application-layer testing should be part of regular development rhythms, just like performance testing or CI/CD integration.
References & Further Reading
📄 DATA-PROVE VAPT Report — DP216 (November 2025)
📚 OWASP Top 10 (2021) — latest official version as of 2025
🔒 Security and Privacy Overview
Top comments (0)