Services · Web applications

Web application penetration testing

Scanners find the obvious issues. They cannot tell whether one customer can read another customer's orders, whether a coupon works twice or whether an admin action trusts whatever the browser sends. A tester can. We test your web application and the API behind it, following the OWASP Web Security Testing Guide (WSTG), and a tester confirms every finding before it reaches your report.

Message us on WhatsApp See our services

What we test

We test your application against the areas of the OWASP WSTG that apply to it. That covers the OWASP Top 10 and the business logic only your application has.

Configuration and deploymentWSTG-CONF
Exposed admin pages, default settings, forgotten files and HTTP security headers.
Accounts and loginWSTG-IDNT, WSTG-ATHN
Registration, login, password reset, one-time passwords and account lockout.
Access controlWSTG-ATHZ
Whether users can reach other users' data or admin functions, including BOLA / IDOR and privilege escalation.
SessionsWSTG-SESS
Session tokens and cookies, logout, timeouts and cross-site request forgery.
Input handlingWSTG-INPV
Injection such as SQL injection and cross-site scripting, and server-side request forgery.
Errors and cryptographyWSTG-ERRH, WSTG-CRYP
Error messages that leak details and weak TLS or encryption.
Business logicWSTG-BUSL
Prices, coupons, wallets, loyalty points, bookings, approval steps and file uploads, and any step that can be skipped or repeated.
The browser sideWSTG-CLNT
DOM-based cross-site scripting, clickjacking and cross-origin resource sharing.
APIsWSTG-APIT
The REST and GraphQL APIs your application depends on, including mass assignment and rate limits.

Small issues, big impact

We chain low-severity issues into the high-impact attack paths that scanners miss. One endpoint that lists user IDs and another that skips a permission check might each rate low on their own. Together they can expose every customer's data, and the report shows the full path.

When to test

Before launch or a major release, so you fix problems before your customers find them.
When you add new features such as payments, a wallet, loyalty points or new user roles.
When a regulator asks. ECC control 2-11-3-1 lists websites and web applications among the internet-facing services entities in scope must test. SAMA's Cyber Security Framework (3.2.4) calls for annual penetration tests of customer and internet-facing services. Where you handle card data, PCI DSS v4.0.1 Requirement 11.4 covers penetration testing. See NCA ECC and SAMA CSF.
When a customer or investor asks for a recent penetration test report.

Black, grey or white box

Black box: no accounts or inside knowledge, so you see what an outsider sees.
Grey box: a test account for each user role, so we can test what logged-in users can reach. We recommend it for most web applications.
White box: access to the source code as well, so we can look deeper.

What we need from you

The address of each web application in scope, for example app.example.com
A test account for each user role, for example customer and admin
An environment to test against, ideally staging. If we test production, we agree testing windows and stop conditions first
API documentation, such as an OpenAPI file or a Postman collection, if you have one

Before testing starts, we give you the IP addresses we will test from.

What you receive

An executive summary of your risk in business terms
A technical findings report with CVSS scores, evidence and reproduction steps, so your developers can confirm each finding themselves
A remediation roadmap with guidance for your stack rather than generic advice
Findings mapped to the frameworks you report against, such as NCA ECC, SAMA CSF, PDPL, ISO 27001 or PCI DSS
A record of the WSTG areas the test covered
A readout session with your team
One retest of all confirmed findings within 90 days at no extra cost, then a closure letter recording the status of each finding

If we confirm a critical finding, we tell your named contact within 24 hours, so you do not have to wait for the final report.

How long it takes and what it costs

A web application test typically takes one to three weeks from kick-off to report, depending on the number of roles, endpoints and business flows in scope. We confirm the timeline and a fixed price in the statement of work. There is no hourly billing, and the retest is included.

Common questions

Is an automated scan enough?

Scanners find the obvious issues. A scanner cannot judge whether a price, a coupon or a permission check behaves the way your business intends. That is why a tester confirms every finding.

Will testing slow down or break our site?

We plan every test to avoid disruption. Before we start, we agree testing windows, request rates, stop conditions and an escalation contact, and you can pause or stop testing at any time. Destructive techniques are excluded unless you authorise them in writing. Our Testing Safety Policy sets out every safeguard.

Our application sits behind a web application firewall. Is that a problem?

No. We can test what an outside attacker would face, or you can let our IP addresses through so we test the application itself. We agree which before testing starts.

Our site runs on a hosted platform. Can you test it?

We test what you control, such as your configuration, your own code and your integrations. The platform itself is tested only where its provider's policy allows it or with the provider's permission.

Can the report be in Arabic?

Yes. You choose Arabic, English or both for every deliverable.