SchellmanCON is back! Join us for our virtual conference on March 6 & 7, 2025

Contact Us
Services
Services
Crypto and Digital Trust
Crypto and Digital Trust
Schellman Training
Schellman Training
Sustainability Services
Sustainability Services
AI Services
AI Services
About Us
About Us
Leadership Team
Leadership Team
Corporate Social Responsibility
Corporate Social Responsibility
Careers
Careers
Strategic Partnerships
Strategic Partnerships

The Insider’s Guide on Getting A Better Web App Pen Test

Penetration Testing

Published: Feb 14, 2025

Web applications grow and evolve each year. There’s always a new feature, a new API, and a new way of doing things. These constant changes may introduce some form of vulnerability, which is not ideal when web applications often sit on your external network. This makes web applications an ideal vector for an attacker to migrate into your internal network or compromise customers. Therefore, any web application test deserves an adequate level of thoroughness and attention. Below, we’ve provided a list of questions you should consider asking prospective pen test providers to ensure the most effective web application pen test experience. 

These questions will help you identify if a pen test provider is right for you, as well as reduce the risk of pitfalls and miscommunications: 

How long will the test take? 

A suspiciously short timeline may indicate a scope miscommunication, or at worst, a low-quality provider. However, keep in mind that overall scope dictates engagement length, in addition to the number of resources assigned. 

We can’t speak for all providers, but at Schellman, we typically expect 1-2 weeks for small/medium web applications. For large and/or multiple applications, 3-4 weeks is about average. 

Will web application testing be conducted from an authenticated standpoint? 

A thorough test of your web application can be split into two components:

  1. What an outsider can access without logging in
  2. What an authorized user can do after logging in
The first component examines publicly-facing elements, such as the login page and any openly accessible parts of your application, looking for security weaknesses. However, if your application allows users to log in, it’s crucial that testers also examine the “protected” areas of your site. Without testing this area, many potential security issues could go undetected, as most of your application’s functionality is likely locked behind the login screen. 

What will your team do if they run into broken functionality? 

Even after a web app is past QA, it’s possible certain functionality can break before or during testing. Ideally, the tester should notify your team as soon as possible to avoid impediments. At worst, failure to report broken functionality can result in missed scope. 

Does your team conduct manual testing? 

For all forms of web testing, we believe that automated testing is not a replacement for manual testing. Web application intricacies often require a human to identify and adapt for unique test cases – more on this later. 

Does your team test for authorization vulnerabilities, such as authorization bypasses, role testing and/or Insecure Direct Object References (IDORs)? 

Each of these vulnerabilities are very real, but are currently incredibly difficult to catch with automated tests (DAST or SAST). Generally speaking, semi-manual or completely manual request rewriting is done to test for each of these vulnerabilities. Therefore, if your provider is only doing automated testing, there’s a significant possibility that multiple vulnerability classes are being missed. 

Will tenant-to-tenant testing be conducted? (i.e. can tenant A see tenant B’s data?) 

If your web application supports multiple tenancies, or if some user data should be private to only that specific user, this attack vector should absolutely be included. Ultimately, this is just another form of authorization testing; therefore, the same rules apply as per the prior answer: this test case is troublesome with automated testing. 

It's important to note that if your provider is testing this vector, they should ask for or register multiple accounts. If they are only testing using a single account, then it is usually very difficult for them to test for cross-tenant issues without significant guesswork. 

What industry methodology do you use? What about test cases which may not be in the methodology yet? 

First and foremost – while the OWASP Top 10 is great, we should mention that some revisions historically did not cover all vulnerability classes. As such, it’s important to know which revision of the OWASP Top 10 is being tested. Next, the OWASP Web Security Testing Guide (WSTG) is preferred as it is much more exhaustive. However, it’s important to note that testing doesn't need to be limited to a certain standard. After all, new vulnerability classes are discovered yearly, often before industry standards can catch up. 

It is the provider’s job to stay on top of new developments in the cybersecurity landscape. Therefore, as the provider conducts the pen test, they should focus on identifying these issues which are relevant to your application’s technology stack and feature set.  

Will you need a demo or documentation to test our application? 

Many web applications are simple to use and designed for everyone. However, there’s also web applications designed for experts with a dizzying number of non-intuitive features. That being said, while pen testers are experts at cybersecurity, they may not be an expert in your application’s business use case. For these scenarios, the provider should ask for a hands-on demo with an application user or developer user. Documentation may suffice in lieu of a demo, depending on the nature of the application. 

Would your team like access to the application’s source code? 

While likely not a requirement, and not the norm, a source code assisted penetration test will assist testers in finding vulnerabilities. Beyond this obvious advantage, there are several valuable but often overlooked benefits:

  • Some vulnerabilities are difficult to discover through manual testing alone 
  • Testers may identify the exact code line(s) responsible for the vulnerability 
  • For already discovered vulnerabilities, testers can easily review the code for similar instances 
  • Testers will be more likely to convert theoretical vulnerabilities into real exploits 
  • Testers may be able to confirm vulnerabilities without crucial development team time 

Finding a Pen Test Provider That Meets Your Needs

It’s essential that your pen test provider understands the complexities and nuances of web application testing. By asking the right questions about their methodology, you can more closely align the right provider with your needs. A provider’s answers will reveal not only their technical expertise, but also their commitment to thorough, professional testing. 

If you’re considering a web application pen test and our methodologies resonate with your security goals, we invite you to learn more about our approach. Our brief pen test scoping questionnaire can help us start the conversation about your specific needs and objectives.

About Austin Bentley

Austin Bentley is a Manager at Schellman, headquartered in Kansas City, Missouri. With a robust background in penetration testing, Austin has developed a distinctive procedural methodology that sets his assessments apart. His expertise spans various forms of penetration testing, ensuring comprehensive security evaluations. Before stepping into his managerial role, Austin honed his skills in Application Security at a major financial institution, where he was instrumental in safeguarding critical systems.