Websites, applications and the systems behind them
A public information website, an online shop and a customer portal have different functions, but all may expose security-relevant components. A simple site can still include forms, an administration area or third-party integrations. An application may also serve mobile clients and external partners through interfaces not obvious from its browser pages.
An application programming interface (API) allows software components to exchange requests and data. Testing only the visible screens can miss API operations, older endpoints or functions intended for different roles. Establish which interfaces and environments belong to the assessment before testing begins.
Coverage should follow the business process: who can perform an action, what information it uses and where the result goes. The OWASP Web Security Testing Guide is a useful reference for test areas, but applying it well requires understanding the application rather than treating every entry as equally relevant.
Authentication, authorisation and sessions
Authentication: establishing identity
Authentication checks whether someone can prove the identity they claim. Relevant paths can include login, password recovery, multi-factor authentication, account enrolment and alternative interfaces. Testing should consider whether a weaker recovery or legacy route undermines a stronger main login. The exact checks depend on the identity system and agreed access.
Authorisation: enforcing permitted access
Authorisation determines what that identity may read or change. Test boundaries between users, roles and organisations, including individual records and privileged functions. Hiding an administrative button in the browser is not a server-side permission check. A valid login must not give an ordinary user access to another customer’s data.
Sessions: maintaining and ending access
Sessions connect subsequent requests to an authenticated state. Assessment can examine token handling, expiry, logout, changes of privilege and the effect of account recovery or suspension. Cookie settings and browser behaviour matter, but the server must also reject invalid or no-longer-authorised sessions where the design requires it.
These controls interact. A correct login does not compensate for weak record-level permissions, and a hidden page does not become protected simply because its address is difficult to guess. Testing with representative roles is usually more informative than using only a single administrator account.
Input handling, output handling and files
Applications receive values through forms, URLs, API bodies, headers, uploaded files and other channels. Testing asks whether those values can cross an intended boundary when stored, queried, displayed or passed to another component. Validation needs to match the expected type and business rule, while the receiving operation needs appropriate protection.
For example, database queries should not treat untrusted text as executable query structure, and browser output needs context-appropriate encoding. Cross-site scripting concerns script execution in a user’s browser; it is not the same issue as a server interpreting a database command. Findings should identify the affected component and effect rather than grouping every input problem under one vague label.
Where uploads exist, assess who can upload and retrieve files, permitted types and sizes, storage location and any processing pipeline. A filename extension alone does not establish safe content. Previewers, document converters and public download links may introduce separate controls to review. Use harmless test files and agreed limits rather than disruptive content.
APIs need their own access and data checks
An API may expose more operations or fields than the browser interface uses. Assess whether each operation enforces the correct identity, record ownership and permitted actions. The fact that an endpoint normally receives requests from a particular frontend does not make incoming requests trustworthy.
Check what information the service returns as well as what it accepts. A page may display only a customer name while the underlying response contains unnecessary sensitive fields. Also examine whether a client can supply fields that the server should control, such as an approval state or account privilege.
Rate controls and limits on expensive operations may be relevant, but testing them requires explicit safeguards. Demonstrating excessive resource consumption does not justify exhausting a production system. Agree safe evidence thresholds and coordinate with operational owners. Related API concepts are described in the OWASP API Security Top 10.
Business logic: can legitimate features be misused?
Business-logic testing examines whether an application enforces the intended sequence, limits and authority of a workflow. Individual requests can appear valid while their combination produces an unauthorised result. Examples include approval processes, account changes, ordering, entitlement checks and export functions.
This work requires the business owner to explain the rules. A tester cannot reliably determine whether a discount, transfer or approval is improper without knowing who is allowed to initiate it and which conditions must hold. Tests should use synthetic records and controlled effects, with any transaction limits agreed beforehand.
Hypothetical example
A fictional customer portal allows an ordinary account to request a report, but requires a supervisor to approve its release. In a test environment, an ordinary test account receives a synthetic report without the required approval. The finding is the server’s failure to enforce the workflow rule, not merely that a button was visible.
Evidence should show the intended rule, account roles, relevant request sequence and the report’s test identifier. The remediation direction is to enforce approval and ownership at the operation that releases the report. Retesting should cover the blocked ordinary-user path, the valid supervisor path and any alternative API route.
Configuration and sensitive-data handling
A deployment can expose risk through unnecessary administration interfaces, verbose errors, old backup files, insecure defaults or inconsistent settings between environments. Review the application’s actual deployment, not only its source code or a presumed reference configuration.
Transport Layer Security (TLS) protects communications in transit when correctly configured and used. It does not establish that an authenticated user is entitled to every record they request. Similarly, security headers can provide useful browser protections, but a missing header and a demonstrated data-access failure should not automatically receive the same severity.
Sensitive data may appear in responses, exports, logs, browser storage, caches or error messages. Assess whether the recipient needs it and whether retention or exposure creates a security concern. Use synthetic records where practical. The report should avoid unnecessarily reproducing personal or confidential information merely to make a finding look convincing.
Server-side and client-side controls work together
The server must enforce identity, permissions and business rules for operations it controls. Browser-side validation can improve usability, but users and software clients can send requests that do not follow the intended screen flow. Testing should therefore examine the receiving operation, not stop at the visible form.
Client-side behaviour also matters: the page may handle sensitive tokens, display untrusted content or communicate with another origin. A browser restriction is not interchangeable with server authorisation. For example, a cross-origin policy does not by itself decide which records an authenticated API caller is allowed to retrieve.
Map third-party boundaries carefully. A payment, identity or file-processing provider may be outside the authorised scope even though the application integrates with it. Testing your integration does not automatically permit probing the provider’s wider platform.
Automated scanning and human investigation
Scanners can efficiently discover routes and identify certain known patterns, configuration issues and input-handling weaknesses. Their reach depends on authentication, navigation, supported technology and configuration. A report should state which functions were reached and whether testing covered more than the public login page.
Human investigation adds understanding of roles, context and multi-step workflows. It can challenge an assumption about ownership, inspect a suspicious tool result or establish why a scanner alert does not apply. Neither a long automated report nor a small number of manually demonstrated findings proves exhaustive coverage.
Agree whether the work includes source-code review, authenticated testing or other techniques rather than assuming they are part of every package. Penetration testing can investigate controlled exploitation and connected attack paths where this depth is needed. The useful distinction is what the engagement will establish, not the marketing label.
What should a business prepare?
- Scope and ownership: identify applications, APIs, environments, domains and third-party exclusions.
- Architecture and workflows: explain important data flows, trust boundaries and business rules.
- Test accounts: provide representative users, privileged roles and separate organisations where relevant.
- Safe test data: supply synthetic records and agree how uploads, messages, payments or other effects will be contained.
- Operational arrangements: agree written authorisation, rules of engagement, windows, limits, contacts and stop conditions.
- Evidence access: arrange appropriate application logs, documentation and a route for clarifying unexpected behaviour.
A representative test environment can reduce risk, but differences from production must be recorded. Missing integrations or different permissions may limit conclusions. Where production testing is necessary, agree specific safeguards rather than assuming that any test is harmless because it is authorised.
From findings to remediation and retesting
A useful finding identifies the affected function, prerequisites, observed behaviour and business consequence. Evidence should be sufficient to reproduce the issue under agreed conditions, while protecting sensitive information. Severity should reflect the demonstrated result and relevant context; suspected wider impact should be clearly distinguished from confirmed facts.
Remediation recommendations should identify the failed control and an appropriate correction. A general instruction to “improve validation” may not help an engineer repair a missing ownership check. The assessment should state limitations and assign unresolved questions, rather than convert uncertainty into an exaggerated claim.
After changes, security retesting and validation checks whether the original issue and relevant variants are resolved. Include legitimate workflows so a fix does not simply disable useful functionality. Findings that remain partially corrected need an accurate status and follow-up, not automatic closure because a code change was deployed.
Frequently asked questions
Is web application testing the same as checking a website with a scanner?
No. Scanning can support testing, but application security also involves identities, permissions and business workflows that require context and validation. Confirm the actual coverage and techniques.
Does a site without customer logins need testing?
It can. Forms, administrative access, uploaded content, deployment configuration and integrations may still create security risks. Tailor the scope to the functions that exist.
Can APIs be tested without a browser interface?
Yes. API documentation, representative credentials and an understanding of data and business rules can support direct interface testing within an authorised scope.
Will testing prove that every vulnerability has been found?
No. Conclusions are bounded by scope, access, methods and time. The report should explain limitations and the evidence behind each finding.
Do developers need to provide source code?
Not for every engagement. Interface-based testing is possible without code, while code-assisted work may provide additional coverage. Agree the access and approach beforehand.
Should fixes be retested before closure?
Yes, where verification is appropriate to the finding. Retesting establishes whether the control works under relevant conditions and records any remaining limitations.
AUTHORISED SECURITY TESTING
Get evidence about the controls your application relies on.
Discuss your users, workflows and interfaces to define an authorised assessment with useful findings and remediation guidance.
See how application testing fits into our wider cybersecurity testing services.