In short
The portals, line-of-business apps and logins your team depends on hold a lot of trust and a lot of data. Application testing looks at the logic behind the login, where the flaws that matter usually live. Testing follows the OWASP Web Security Testing Guide and Application Security Verification Standard.
The software your business runs on holds a great deal of trust and a great deal of data. Client portals, line-of-business applications, the logins your team uses every day. Each one is a place where a mistake in logic, rather than a missing patch, can expose everything behind it.
Application testing looks at that logic. It is a different exercise from scanning a server, and it finds a different class of problem.
Why scanners miss the important flaws
A vulnerability scanner is very good at recognising known-bad versions. It is close to useless at understanding what your application is for.
Consider an invoice portal. The scanner confirms the web server is patched and the certificate is valid, and reports the application clean. What it cannot notice is that changing /invoice/1041 to /invoice/1042 in the address bar returns another customer's invoice, because the application checks that you are logged in but never checks that the invoice is yours.
That is a broken access control, and it is consistently among the most common serious findings in web applications. No scanner will find it, because nothing about it is technically malformed. It requires someone to understand the business rule and then deliberately break it.
What testing covers
Work follows the OWASP Web Security Testing Guide, with the Application Security Verification Standard used to set the depth of assurance. In practice, the areas that repay attention most are:
- Authentication and session handling. Whether sessions expire, whether they are properly invalidated at logout, whether password reset can be abused to take over an account.
- Authorisation. Whether one user can reach another's records, and whether a standard user can reach an administrative function by asking for it directly.
- Input handling. Injection and cross-site scripting, still present often enough to be worth checking every time.
- Business logic. Discounts that can be applied twice, workflow steps that can be skipped, quantities that accept negative numbers.
The last category is where the genuinely expensive findings tend to sit, and it is the one that only a person can test.
Which applications are worth testing
Not everything needs a full assessment. The ones that do share these traits:
- They handle sensitive or personal data, which brings GDPR into the conversation
- They support a critical workflow, so downtime or corruption stops the business
- They are reachable by people outside your organisation, whether customers, suppliers or remote staff
An internal application still deserves attention if it could be abused by an insider, or by an attacker who has already gained a foothold on the network. Internal does not mean unreachable.
Bought software is still your responsibility
A common assumption is that a purchased platform has been tested by its vendor, so there is nothing to check. Two problems with that.
First, the vendor tested their product in their configuration. Yours will differ, and most of the serious findings we see in commercial platforms come from configuration and integration rather than from the vendor's code.
Second, the data is yours and the regulatory responsibility is yours. If a client portal you licensed exposes your customers' records, the conversation with the Data Protection Commission is yours to have.
Testing does not stop at the login page
The most valuable part of an application test usually happens after authentication. Anonymous testing tells you whether the front door holds. Authenticated testing, using accounts at each privilege level you actually issue, tells you whether the internal walls hold.
We ask for a test account per role. Without those, an assessment can only ever describe the perimeter of the application, which is rarely where the risk is.
What you get
A report that names each finding, shows the request and response that demonstrate it, explains the business consequence in plain terms, and gives a specific remediation step. Where the application is third-party, the write-up is prepared so that you can hand it straight to the vendor without editing.
Retesting after fixes is included, because a finding is not closed until it has been shown to be closed.
Where this fits
Application testing sits alongside external attack-surface testing, which finds what is reachable, and internal testing, which measures how far a foothold travels. Applications are usually the part with the most direct route to the data.
To scope an assessment of the software your business runs on, talk to us or read more about penetration testing and vulnerability scanning.