Web Application Penetration Testing
A web application penetration test is the controlled testing of an application's authentication, authorisation, data handling and workflow layers using real attacker techniques. Nokta Guard runs this test primarily by hand, based on the OWASP Web Security Testing Guide (WSTG) and the OWASP Top 10 categories. Every finding is reported with evidence, a CVSS score and a practical fix.
Most corporate data is processed in web applications. Automated scanners find known technical flaws, but business logic flaws, such as bypassing a discount, an approval or a permission step, are only found by a specialist who understands the application the way a user does.
Automated scanning is only the starting point; every finding is verified by a specialist and false positives never reach the report.
Control Scope
areas · OWASP WSTG · PTES
Authentication and session management
Password policy, multi-factor authentication, session fixation, concurrent sessions and the token lifecycle.
Authorisation and access control
Horizontal and vertical privilege escalation, insecure direct object references (IDOR) and server-side enforcement of every permission.
Input validation and injection
SQL, NoSQL, command and template injection, cross-site scripting (XSS) and server-side request forgery (SSRF).
Business logic and workflow
Skipped approval steps, manipulated prices and quantities, replayed one-time actions and race conditions.
APIs and web services
Object-level authorisation and excessive data exposure on the REST, GraphQL and SOAP endpoints the application uses.
Configuration and deployment
Security headers, TLS settings, exposed admin panels, default accounts and forgotten backup or test files.
Client-side security
DOM-based XSS, Content Security Policy, CORS, clickjacking and sensitive data left in the browser.
Cryptography and data protection
Encryption in transit and at rest, password hashing, key management and masking of personal data.
Error handling and logging
Error messages that leak internal details and whether security events are logged.
Testing is manual-first. Automated tools are used only to map the attack surface; our consultants test authentication, authorisation, session handling and business logic from the point of view of every user role. Grey box is the most common approach, so we ask for a test account for each role.
Duration depends on the number of screens and endpoints, the user roles and the test approach. We confirm the timeline in the proposal after scoping. Critical findings are shared with you immediately, without waiting for the report.
Executive summary and overall risk assessment. For each finding: affected URL, evidence (request/response, screenshots), reproduction steps and CVSS score. Prioritised remediation advice. A retest report once fixes are in place.
Customer portals, e-commerce sites, internet banking and internal business applications. Recommended before a new application goes live, after a major release and when a regulator or customer asks for it.
FAQ
We have gathered our most frequently asked questions with quick, clear answers.
How long does a web application penetration test take?
Is testing done in the live environment?
Do we need to give you source code access?
Are fixes verified after the engagement?
Which obligations does this test meet?
Web application security is a shared control area across audit, data protection and critical infrastructure obligations.
Related content
Selected content to help clarify scope before testing and prioritise findings correctly.
Related Pages
Penetration testing and audit readiness in finance
Test scope, reporting expectations and FAQs for organisations subject to BRSA, CMB and CBRT regulations — all on one page.
01
Introduction and sector security approach
Financial institutions are the most tightly audited sector because of customer data, payment flows and service continuity obligations. The BRSA Regulation on Information Systems and Electronic Banking Services requires banks to have penetration tests carried out regularly by independent teams.
- At least once a year
- External, qualified team
- Internet, mobile, internal network
02
Sector-specific risks
The areas attackers target most often in financial institutions.
-
Account takeover
Unauthorised access to customer accounts and fraud through authentication and session vulnerabilities.
-
Payment and card data
Payment flow manipulation, card data leakage and loss of transaction integrity.
-
Open banking APIs
Authorisation flaws and excessive data sharing in third-party integrations.
03
Test scope topics
Scope is defined together based on the organisation's service channels and architecture.
- Internet and mobile banking applications
- Payment systems and card infrastructure
- Open banking and enterprise APIs
- External network and internet-facing services
- Internal network, Active Directory and privilege escalation
- SWIFT and critical business applications
- Social engineering and phishing tests
- Call centre and IVR security
04
Use in reporting and audits
The report is prepared to be used directly as evidence in internal audits and BRSA reviews.
- Executive summary and overall risk score
- Each finding mapped to the relevant regulation article
- Evidence screenshots and reproduction steps
- Prioritised remediation plan
- Retest result and closure letter
Penetration Test Report
- Critical
- High
- Medium
- Low
05
Sector-specific FAQ
How often does BDDK require penetration testing?
Can a bank's own team perform the BDDK penetration test?
Which systems should a BDDK penetration test cover?
How long does a BDDK penetration test take?
06
Preselected quote form
Page context is carried into the form automatically; visitors don't have to choose a service.
The “Requested service” and “Sector” fields are preselected from this page.
Go to Form