Architecture, OWASP Flaws, and Assurance
Published: October 2026 | Estimated Reading Time: 9 minutes | Focus: Application Security, CREST Assurance & DevSecOps
Web applications and APIs are central to how businesses operate in the UK, but attackers can easily target them. Unlike automated scanners, web application penetration testing uses certified ethical hackers to find code flaws, weak authorisation, and complex business logic issues. Independent, CREST-accredited testing helps meet compliance requirements like UK GDPR, PCI DSS, and ISO 27001, while also protecting company data and customer trust.
Web applications, customer portals, single-page applications (SPAs), and cloud-hosted APIs make up the digital backbone of modern business operations.
Organisations use these platforms to process payments, store customer data, and provide automated services. Because these platforms are so accessible, their complex code is exposed to the public internet.
Standard boundary defences like next-generation firewalls and endpoint security software cannot detect attacks hidden in normal HTTP or HTTPS traffic. If an attacker bypasses authentication, changes an API parameter, or injects malicious code into a search field, traditional network controls often see this as normal user activity.
To protect customer-facing platforms, organisations need to conduct independent penetration testing of their web applications.
By simulating real-world attacks in a safe environment, organisations can find design flaws, bugs, and logic gaps before attackers do.
Defining Web Application Penetration Testing: The Technical Bit
Web application penetration testing, often called “web app pen testing,” is a technical process in which qualified security experts attempt to breach a web application, its APIs, and backend databases.
Certified ethical hackers use both automated tools and manual testing, rather than relying only on passive scanners. They look for vulnerabilities across all layers of the application, assess their real-world impact, and provide clear steps for fixing them.
Automated Vulnerability Scanning vs Manual Penetration Testing
Many in enterprise IT mistakenly think automated Dynamic Application Security Testing (DAST) is the same as an accredited penetration test.
Automated scanners help find vulnerabilities in known software, but they cannot understand business workflows or spot subtle permission issues.
| Feature / Capability | Automated Vulnerability Scanning | CREST Manual Penetration Testing |
| Detection Methodology | Signature-based checks and automated crawlers. | Adversary emulation, manual code exploration, and contextual fuzzing. |
| Business Logic Testing | Incapable of evaluating multi-step application logic. | Evaluates workflows (e.g., checkout manipulation, role escalations). |
| False-Positive Handling | High volume of unverified alerts and scanner noise. | Manually verify and confirm all findings before reporting. |
| Authentication & State | Frequently drops complex sessions or multi-step MFA. | Tests across all authenticated user roles and privilege tiers. |
| Exploit Chaining | Evaluates isolated parameters in a vacuum. | Chains low-level information leaks into critical administrative access. |
| Audit Credibility | Rarely accepted by cyber insurers or enterprise panels. | Formally accepted by CREST, PCI DSS QDFs, and regulatory bodies. |
Core Vulnerabilities Identified in Web Application Testing
These thorough evaluations follow international standards, mainly the OWASP Top 10 and the OWASP API Security Top 10, to cover the main types of vulnerabilities:
-
Broken Object Level Authorisation (BOLA / IDOR)
In modern REST and GraphQL APIs, Insecure Direct Object References (IDOR) happen when an application does not check if a user is allowed to access a certain resource. For example, an attacker might view other customers’ data by changing an account ID parameter, such as changing/api/invoice?id=1004 to/api/invoice? id=1005.
-
Injection Flaws (SQLi, NoSQL, and Command Injection)
Injection occurs when an application sends untrusted input to an interpreter without proper checks or parameterised queries. If attackers succeed with SQL Injection (SQLi), they can bypass authentication, access database contents, change records, or even run commands on the server if security is weak.
-
Cross-Site Scripting (XSS)
Flaws which allow attackers to inject malicious JavaScript into web pages that are viewed by othThese flaws let attackers inject malicious JavaScript into web pages seen by other users. When XSS payloads run in a victim’s browser, attackers can steal session cookies, log keystrokes, redirect users to fake sites, or perform actions without permission. Session tokens are generated, or session timeout procedures are handled, can allow adversaries to take on the identity of valid accounts and circumvent multi-factor authentication (MFA) systems if the tokens have insufficient entropy, do not get invalidated when a user logs out, or reveal sensitive information through unencrypted parameters.
-
Application and Business Logic Flaws
Some vulnerabilities are built into the application’s design and automated tools can’t find them. For example, attackers might change item prices during checkout, skip steps in onboarding, or use race conditions to redeem promo codes multiple times.6. Security Misconfigurations & Information Disclosure
Examples include misconfigured HTTP security headers (like Content Security Policy, HSTS, and X-Frame-Options), error messages that reveal software or database details, and default admin portals that are open to the public internet.
The Penetration Testing Lifecycle: A Structured Approach
Penetration testing follows an accredited process designed to keep the application safe while checking its technical controls. This approach provides reliable assurance.
- During the planning stage, teams decide if the test will be White-Box (full access to documentation or code), Grey-Box (access to credentials), or Black-Box (no insider information). This clarifies the boundaries for testing.
- Reconnaissance involves finding endpoints, hidden directories, client-side scripts, and third-party dependencies.
- Testers manually test input fields, API routes, and session tokens for vulnerabilities.
- Technical reports document each confirmed vulnerability, its CVSS score, proof-of-concept code, the business impact, and clear advice for developers on how to fix it.
- After fixes are made, testers review the changes with software engineers and retest to make sure the vulnerabilities are closed and no new issues have appeared.
Commercial and Regulatory Drivers: The Value of Independent Testing
Testing web applications is not just about meeting technical standards. It is a vital business need for UK organisations:
- The UK GDPR and the Data Protection Act 2018, under Article 32, make it explicitly necessary for organisations to put in place ‘a process for regularly testing, assessing and evaluating the effectiveness of the technical and organisational measures meant for ensuring the security of the processing’. Evidence of independent testing provides an important defence against sanctions imposed by the Information Commissioner’s Office (ICO).
- Requirement 11.4 of PCI DSS 4.0 makes it strictly necessary to carry out regular internal and external penetration tests on all systems that store, process, or transmit cardholder data, including those tests following any major change to the infrastructure or to the code.
- Large companies, government bodies, and legal firms often require an independent Letter of Attestation or a summary of a penetration test before approving SaaS software or vendor integrations.
- Commercial underwriters now require independent testing before approving high-value cyber insurance or settling claims after an incident.
Frequently Asked Questions (FAQ)
What is the difference between penetration testing of web applications and penetration testing of the infrastructure?
Infrastructure penetration testing focuses on basic network components like routers, firewalls, VPN gateways, operating system settings, and network services such as SSH, SMB, and RDP. Web application penetration testing, by contrast, examines custom code, business logic, session handling, database queries, and APIs. Both types of testing are needed for full security assurance.
Can carrying out penetration testing lead to disruptions of live customer services or result in downtime?
Professional penetration tests are planned to avoid disrupting operations. During planning, teams agree on the testing schedule, request limits, and methods. Teams can run tests in staging, UAT, or pre-production environments that mimic live systems. If testing must be done on live systems, certified testers monitor performance and stop if they notice high latency.
How frequently should an organisation hire a penetration tester for its web application?
Standards like ISO/IEC 27001 and the NCSC Cyber Assessment Framework (CAF) recommend testing at least once a year. Additional tests should be done after major code changes, architecture updates, new features, or database changes.
What kind of information is needed to plan a penetration test of a web application?
To plan a penetration test properly, you need high-level architectural details:
- The URL of the application in question (whether it is in production or staging).
- The number of different user roles or levels of privilege (for example, Unauthenticated Guest, Standard Customer, Tenant Admin, Super Administrator).
- The number of dynamic forms, data inputs, or page templates, approximately.
- The availability of API documentation (for example, Swagger, OpenAPI, or Postman collections).
- Things such as third-party integrations (for example, payment gateways or single sign-on providers).
Why is CREST accreditation important when choosing a penetration testing provider?
CREST (Council of Registered Ethical Security Testers) is considered the leading standard for offensive security in the UK and worldwide. CREST accreditation means testing follows standard methods, data is handled confidentially, and consultants have certified technical qualifications, such as CREST Registered Tester or Certified Web Application Tester.
What constitutes an Attestation of Security, and why does procurement request it?
A Security Attestation, or Letter of Attestation, is a document from an independent testing organisation after a project is completed and retested. It proves the application was tested to recognised standards like OWASP and CREST, and that vulnerabilities were fixed. This document satisfies procurement panels, risk assessors, and auditors without sharing sensitive technical details.
Secure Your Web Platforms with Independent Accredited Testing
Relying on assumptions or automated tools leaves applications open to attacks. Only independent technical testing can find code and logic flaws early, helping protect your business and meet regulatory requirements.
CREST-Accredited Application Security Services
Cyber Security Specialists offers accredited technical testing, vulnerability audits, and remediation consulting to protect web applications and enterprise platforms:
- Manual penetration testing covers custom web applications, customer portals, and microservices, following the OWASP Top 10 guidelines.
- API security assessments include detailed reviews of REST, SOAP, and GraphQL architectures to find BOLA/IDOR vulnerabilities, data exposure, and access control issues.
- Mobile application penetration testing includes analysing client-side code, auditing local storage, and testing APIs on both iOS and Android platforms.
- The CS360.ai Attack Surface Management system monitors external digital assets in real time, detecting shadow IT subdomains, expired certificates, and open ports.
To discuss your testing needs, request a proposal, or speak with an accredited consultant:
Telephone: 0161 706 0244
Email: info@cybersecurityspecialists.co.uk
Related Pages
