Web Applications and APIs
If you've never had a penetration test done on your web application or API, or you've had a bad experience with one, you probably have questions. What do we actually need to prepare? What are you testing? What do we get at the end of it?
This post walks you through what a web application and API penetration test looks like when you work with Parabellyx or our LUMA PTaaS platform, from preparation through to reporting.
Preparing Your Environment
The best thing you can do to set your engagement up for success is to have the right environment ready before testing begins.
We recommend testing against a QA or UAT environment rather than production. There are a few reasons for this. Penetration testing involves sending malicious payloads, fuzzing inputs, and probing for injection and, in some cases, denial-of-service conditions. In production, this can degrade performance for real users, corrupt data, or trigger alerts that pull your operations team into unnecessary incident response. A QA or UAT environment lets our testers work without those constraints, which means more thorough coverage and fewer interruptions to your business.
That said, production testing can be done when there's no alternative. If that's the case, we work with you to define boundaries and testing windows to minimize impact. But given the choice, a dedicated test environment is always the better option.
A few other preparation items:
- The environment should not contain real customer or user data. Use synthetic or anonymized data. This protects your customers and removes any privacy concerns during testing.
- We'll need test credentials. Typically at least two accounts at each privilege level so we can properly assess access control between roles. If you are on LUMA, you can submit credentials securely through the intake form.
- Make sure the environment is fully functional, internet-accessible, and ready to go before the engagement starts. Downtime during a testing window burns time for both sides.
Web Application Firewall Considerations
You'll need to decide how to handle your Web Application Firewall (WAF). You have two options: allowlist our testing IP or leave the WAF in place.
Allowlisting our IP gives us a clear view of the application itself. We're testing your code, your logic, and your configurations without the WAF masking issues. This gives you the most comprehensive picture of where your application actually stands.
Testing with the WAF enabled shows you how your defense-in-depth holds up against real-world attack conditions, but it can block payloads that would otherwise reveal vulnerabilities in the underlying application.
We recommend allowlisting our testing IP. Testing the application directly gives you the most accurate picture of its security, and the WAF remains an additional layer of protection on top of that.
What We Actually Test
We don't hand you a vulnerability scan and call it a penetration test. Our testing methodology is built around the OWASP Application Security Verification Standard (ASVS), which goes well beyond the OWASP Top 10.
Our testers work through a structured checklist that covers:
- Access Control: Can one user access another user's data? Can a low-privilege user perform administrative functions? We test both horizontal and vertical privilege escalation.
- Authentication: How does the application handle login, password reset, multi-factor authentication, and account lockout? Are there weaknesses in how identity is verified?
- Session Management and Cookies: Are sessions properly invalidated on logout? Are cookies configured with the right flags? Can sessions be hijacked or fixated?
- TLS Configuration: Is transport layer security properly configured? Are weak cipher suites or outdated protocol versions in use?
- Error Handling and Information Disclosure: Stack traces, verbose error messages, debug endpoints left enabled, and internal paths or database details leaking in responses. These give attackers free reconnaissance and are often overlooked.
- Security Headers: Content Security Policy, X-Frame-Options, HSTS, Referrer-Policy, and CORS configuration.
- Cryptography and Sensitive Data Storage: Weak hashing algorithms on passwords, sensitive data stored in plaintext, hardcoded secrets or API keys in client-side code, and insecure token generation.
- Injection: SQL injection, cross-site scripting, command injection, template injection, and other input-based attacks across every input vector we can identify.
- Business Logic: This is where automated tools fall short and manual testing matters. We look at how the application's workflows can be abused, things like price manipulation, workflow bypasses, race conditions, and logic flaws specific to what your application does.
- File Upload Testing: Unrestricted file types, path traversal via filenames, oversized uploads, and executable content being served back to users.
- API-Specific Testing: Rate limiting, mass assignment, broken object-level authorization (BOLA/IDOR), excessive data exposure in API responses, and improper function-level authorization. These map directly to the OWASP API Security Top 10.
- Application-Specific Functionality: Every application is different. We spend time understanding what makes yours unique and testing the functionality that matters most to your business.
For API engagements specifically, we recommend providing Swagger documentation or Postman collections. This allows our testers to quickly understand the full API surface and focus on testing rather than discovery. LUMA's intake form accepts these as attachments, along with architecture diagrams and other supporting documentation.
How the Engagement Runs
A typical web application or API penetration test runs between one and two weeks, depending on the size and complexity of the application.
Before any testing begins, a technical lead works with our sales team to understand the complexity and nature of your application. We are moving customers onto our LUMA PTaaS platform, where you complete the scoping and intake forms directly. LUMA clients with credits can also request new services and go through scoping from their dashboard. This ensures the engagement is properly sized and nothing is missed.
We kick off every engagement with a call. Our testers may ask for a walkthrough of the application to understand the intended workflows, user roles, and any areas of particular concern. This upfront investment in understanding your application translates directly to better findings.
Throughout the engagement, your named consultant communicates with you directly over email. You'll know when testing starts, when it wraps up, and when your report is ready. If we find a critical issue during testing, we notify you the same day. If you are on LUMA, your dashboard also shows a timeline of the engagement, including key dates and any next steps for you to complete.
What You'll Receive
When your engagement wraps up, you receive a complete set of deliverables built around your specific application. Our reporting is some of the best in the industry: detailed, practical, and written so that both technical teams and executive stakeholders can use it.
- ASVS Compliance Spreadsheet: A detailed mapping of your application against the OWASP ASVS framework, showing which requirements were tested, which passed, and where gaps exist. This gives you a structured view of your application's security posture.
- Penetration Test Report: The core deliverable. Every finding includes clear steps to reproduce the issue with screenshots and payloads, an assessment of impact and risk, and both strategic and tactical remediation guidance. Strategic recommendations address root causes like architectural changes, secure development practices, or policy improvements. Tactical recommendations give your team specific, actionable steps to resolve the issue now. Your developers should be able to read a finding and know exactly what to fix.
- Debrief Call: We encourage a debrief after you've had a chance to review the report. This is your opportunity to walk through findings with our testers, ask questions, clarify remediation steps, and prioritize what to fix first.
Your report and ASVS spreadsheet are delivered through our LUMA platform as soon as the engagement is complete.
Re-Testing
We encourage re-testing, particularly for any critical or high-severity findings. Once your team has implemented fixes, we can verify that the remediation was effective and that no new issues were introduced in the process. If you plan to re-test, include it in your scope up front so we can schedule it alongside the initial engagement. LUMA PTaaS customers can also request a re-test directly from the engagement dashboard.
Compliance
Whether your penetration test is driven by SOC 2, PCI DSS, or simply good security hygiene, our ASVS-aligned methodology ensures a thorough assessment that goes well beyond a checkbox exercise. You'll receive a report that demonstrates real testing depth, which is what auditors and stakeholders want to see.
Our Team
Our penetration testing staff holds industry-recognized certifications including OSCP, OSCE, CRTO, BSCP, eJPT, eCPPT, OSWA, CEH, and others. Our team is entirely Canadian: every tester on your engagement is based in Canada, with no offshore delivery. More importantly, our testers bring real-world experience to every engagement. Certifications demonstrate baseline competence, but it's our hands-on expertise and methodology that produces meaningful results.
Ready to Get Started?
If you're considering a web application or API penetration test, reach out to our team. We'll walk you through scoping, answer your questions, and make sure the engagement delivers real value for your organization.
