Testing scope

Penetration testing of
web applications and APIs

A customer portal, a shop, a booking system, an internal CRM or the backend of a mobile app. We approach the application the way an attacker with a user account and a browser would: we look not only for classic injections, but above all at permissions and business logic, the places no scanner understands.

  • Manual testing based on OWASP WSTG and ASVS
  • Every role tested separately, plus cross-account access testing (IDOR, BOLA)
  • A step-by-step Proof of Concept for every vulnerability

Web applications and APIs

Duration
usually 5-15 working days
We work to
  • OWASP Web Security Testing Guide (WSTG)
  • OWASP Application Security Verification Standard (ASVS)
  • OWASP API Security Top 10
  • PTES

What exactly we check

We tailor the scope to your environment, but these areas are always covered.

1

Authentication and sessions

Registration, login, password reset, second factor, SSO login. We check token lifetime and revocation, session hijacking, missing attempt limits and account enumeration.

2

Access control

The most common and most costly flaws: IDOR and BOLA, horizontal escalation between accounts of the same type, vertical escalation to an administrator role, data leakage between tenants in multi-tenant systems.

3

Injection and data handling

SQL and NoSQL injection, OS command injection, SSTI, deserialization of untrusted data, XXE, path traversal in file handling and document generation.

4

Business logic

Skipping process steps, price and discount manipulation, negative quantities, reuse of one-time codes, race conditions in payments and limits.

5

APIs: REST and GraphQL

Mass assignment, excessive fields in responses, missing rate limits, introspection and deeply nested GraphQL queries, versioning and forgotten endpoints from previous releases.

6

Browser layer

XSS (reflected, stored, DOM), CSRF, CORS configuration, security headers and CSP, cookie attributes, open redirects, file upload security.

What we find most often

Examples from our projects in this area. Client names and technical details stay in the reports.

  • IDOR in API endpoints granting access to other customers documents
  • SQL injection in a list sorting or filtering parameter
  • Stored XSS in a profile field that executes in the admin panel
  • SSRF in a module that downloads files from a URL
  • JWT accepted without signature verification or with the none algorithm
  • Mass assignment allowing a user to set an administrator role at registration
  • No attempt limit on password reset and one-time codes
  • A forgotten test endpoint exposing production data

Selected tools

Burp Suite Professionalffufsqlmapnucleicustom business-logic scripts

Tools take care of the repetitive work. The conclusions and attack chains are built by hand.

How the test runs and what you get

The testing process, the report format and the retest rules are the same across every scope.

See the full process and report contents

Frequently asked questions

Can the test harm a live application?

By default we work on a test environment with data close to production. If the test has to cover production, we agree on a time window, a list of excluded actions and an emergency contact on your side. We do not run performance tests or denial of service attacks.

What do you need to get started?

The environment address, a description of the roles in the system and test accounts, two per role. Without that there is no way to properly verify access between users. API documentation and repository access are welcome but not required.

How is this different from a vulnerability scan?

A scanner will find outdated libraries and common patterns. It will not check whether user A can see user B invoice, whether an item can be bought for one zloty or whether an approval step can be bypassed. Those flaws cause most real incidents and require manual work.

Do you verify the fixes afterwards?

Yes, retests are included. Once the fixes are deployed we verify every reported vulnerability and update the report with its remediation status.