Web Application Penetration Testing - What It Covers

Web application penetration testing is a controlled, authorized attack on your web application in which a security expert imitates a real attacker to find exploitable vulnerabilities before a malicious actor discovers them. It covers testing of authentication, authorization, business logic, input points (forms, APIs, file uploads) and configuration. The result is a report with proven vulnerabilities, a risk assessment and concrete recommendations for remediation.

Unlike automated scanning, which merely reports potential issues, a penetration test actually attempts to exploit a vulnerability and prove its impact. For example, accessing someone else's data or taking over an administrator account. Below we explain exactly what the test covers, which phases it goes through and how companies in Bosnia and Herzegovina and the wider region can prepare.

Why web applications need a dedicated type of testing

Web applications are the most common entry point for attacks because, by definition, they are exposed to the internet. An online shop, a customer portal, a booking system or an internal application accessible through a browser - these are all targets. A network firewall and antivirus cannot protect against a flaw that originates in the application code itself, for instance when user input is not validated correctly.

This is precisely why web application penetration testing focuses on the application layer, and not only on the infrastructure. It tests the way the application processes data, how it distinguishes between users and what happens when someone tries to bypass the intended usage flow. Many vulnerabilities are not visible from the browser interface; they are only uncovered by an expert who deliberately sends unexpected requests.

Three approaches: black-box, grey-box and white-box

Before the engagement begins, the parties agree on how much information the tester receives. This choice affects the depth and duration of the test:

Approach	What the tester knows	When it is useful
Black-box	Nothing in advance, starts as an external attacker	When you want to simulate a realistic external attack
Grey-box	Has user accounts and basic information	The most common choice, a good balance of depth and cost
White-box	Access to source code and documentation	For the most thorough analysis, e.g. critical applications

For most business applications, the grey-box approach delivers the best result: the tester has at least one user account, so they can also test the area behind the login, where the most sensitive data is usually located.

Phases of a web application penetration test

A professional test follows a structured methodology. Although the details vary, the phases are generally as follows:

1. Agreeing on scope and rules

This defines exactly what is being tested (domains, subdomains, APIs), what is out of scope, in which timeframe and with which limitations. Written authorization is obtained here; without it, testing is not legal. It is also agreed whether the production environment or a dedicated test environment will be tested.

2. Information gathering and mapping

The tester maps the application: which pages exist, which forms and parameters accept input, which technologies are used and what the authentication flow looks like. This phase determines where the potential entry points for an attack are.

3. Vulnerability identification

A combination of automated tools and manual testing. Tools quickly cover breadth, but serious vulnerabilities, especially those in business logic, are only found by an experienced tester through manual analysis.

4. Exploitation

The key difference compared to scanning: the tester attempts to actually exploit the weaknesses found in order to prove their impact. The goal is not to cause damage, but to confirm that the vulnerability is real and to show how far an attacker can get.

5. Reporting and recommendations

The most important deliverable. A good report contains an executive summary, a technical description of each vulnerability, steps to reproduce, a risk assessment (e.g. using the CVSS scale) and concrete remediation recommendations, ordered by priority.

6. Retesting

After your team fixes the shortcomings, the tester checks whether the fixes are actually effective. Without a retest, you do not know whether the problem has truly been resolved.

Which vulnerabilities are most commonly tested

The industry standard for web applications is the OWASP methodology, in particular the OWASP Top 10, a list of the most common and highest-risk vulnerability categories, along with the more detailed OWASP Web Security Testing Guide. Typical areas that are checked include:

• Broken access control - whether a user can view or modify someone else's data or access functions that do not belong to them.
• Injection vulnerabilities - SQL injection and similar flaws where malicious input is executed on the server or in the database.
• Cross-Site Scripting (XSS) - injecting scripts that execute in the browsers of other users.
• Authentication weaknesses - poor session management, weak passwords, lack of protection against brute-force guessing.
• Misconfiguration - exposed administrator pages, unnecessarily detailed error messages, default passwords.
• Business logic flaws - e.g. changing the price in the cart, skipping a payment step or abusing discounts.
• Vulnerable components and libraries - outdated versions with known vulnerabilities.

Business logic flaws require special attention because automated tools almost never detect them. They stem from the way your specific application works.

Testing APIs and modern (SPA) applications

Today's web applications are rarely just a collection of static pages. A large part of the functionality runs through APIs (most often REST or GraphQL) that are called by JavaScript in the browser. This means that a significant part of the attack surface lies outside what the user sees in the interface.

In single-page applications (SPAs) built with tools such as React, Angular or Vue, security logic must never rely on what executes in the browser. An attacker bypasses the interface and calls the API directly. That is why a quality test always also checks the API layer itself: whether all calls are properly protected by authentication and authorization checks, whether parameters can be modified to access someone else's resources and whether the API exposes more data than it should. Many serious vulnerabilities today are found precisely at the API level, and not in the visible part of the application.

A penetration test is not the same as vulnerability scanning

A penetration test is often confused with automated vulnerability scanning. The difference is fundamental:

• Vulnerability scanning is automated, fast and inexpensive, but it produces a list of potential problems, often with false positives. Useful for regular status monitoring.
• A penetration test involves an expert who manually confirms and exploits vulnerabilities, uncovers complex attack chains and logic flaws, and assesses the real business impact.

The best approach is a combination: regular scanning for continuous monitoring and a periodic penetration test for an in-depth assessment. If you run continuous security monitoring, managed detection and response such as the NeoBit Guardian 360 SOC service can help here as well.

How companies in Bosnia and Herzegovina and the region prepare for a test

Good preparation saves time and increases the value of the test. For companies in Mostar and the wider region, we recommend the following steps:

• Inventory your applications and set priorities, starting with those that process payments or personal data.
• Prepare a test environment if you do not want to test production, along with test user accounts of different access levels.
• Notify your hosting provider or service provider if this is contractually required.
• Make sure the development team is available to answer questions and to quickly fix critical findings.
• Agree on scope and expectations in advance, as clear rules prevent misunderstandings during the test.

If you are not sure which scope is appropriate for your application, you can fill out the NeoBit pentest questionnaire and get a rough estimate before committing to anything.

How often to test

The general rule is to carry out a web application penetration test at least once a year, and always after significant changes: new features, migration to a new platform or major changes to authentication. Applications that process payments or sensitive data are usually tested more frequently, and this is often required by security standards or business partners.

A test is only as valuable as the experience of the people who carry it out and how clear and usable the report is. If you are looking for an assessment for your application, get in touch with the NeoBit team and arrange a conversation about scope.

What a quality report contains

The report is the end product you are actually paying for, so it is worth knowing how to recognize a good one. A quality web application penetration test report should contain:

• An executive summary - a non-technical overview of the status and business risks, understandable to the people who make budget decisions.
• A list of findings by severity - each vulnerability is rated (e.g. critical, high, medium, low), most often with a CVSS score for comparability.
• Steps to reproduce - clear instructions on how to confirm each finding, so that your development team can reproduce and understand it.
• Proof of impact - a concrete indication of what an attacker could have achieved, without unnecessarily exposing real data.
• Remediation recommendations - practical, applicable guidance rather than generic phrases, ordered by priority.

A report that merely lists tools and their raw results, without context and recommendations, is a sign that the work was done superficially.

Common misconceptions about penetration testing

In conversations with companies in the region, we often encounter the same misconceptions that are worth clarifying:

• "We have HTTPS, so we are secure." SSL/TLS protects data in transit, but it does not prevent vulnerabilities within the application itself, such as weak access control or injection attacks.
• "We are small, no one will attack us." A large share of attacks is automated and does not choose its target by size, it looks for any vulnerable application available on the internet.
• "We tested once and that is enough." Every new feature can introduce a new vulnerability, so testing is a process, not a one-off event.
• "The scanner showed us everything." Automated tools do not understand business logic and miss the attack chains that only an experienced tester can find.

Frequently asked questions

How long does web application penetration testing take?

The duration depends on the size and complexity of the application and the agreed scope. A smaller application can be tested in a few days, while larger systems with many features and integrations require several weeks. The scope and an estimate of the duration are agreed before the start.

Can a penetration test damage my application or data?

A professional test is carried out in a controlled manner and according to agreed rules, in order to keep risk to a minimum. The goal is to prove vulnerabilities, not to cause damage. Nevertheless, it is recommended to test on a separate environment or with a fresh backup when testing production.

What is the difference between a penetration test and vulnerability scanning?

Scanning is automated and produces a list of potential issues, whereas a penetration test involves an expert who manually confirms and exploits vulnerabilities and assesses the real impact. Scanning covers breadth, while a penetration test covers depth, and it is best to combine the two.

Do I get a report I can show to partners or auditors?

Yes. The result of the test is a structured report with an executive summary, a technical description of the vulnerabilities, a risk assessment and recommendations. Such a document often also serves as evidence of a completed security check for business partners or as part of preparation for standards such as ISO 27001.

Related guides: Cyber security in Bosnia and Herzegovina - the complete guide · Black box, white box and grey box testing - the differences · Penetration testing vs vulnerability scanning - which to choose