Article contents
The security of a website and an API is checked with a web application penetration test: with written permission, a specialist manually tries to do what attackers would do, under every user role and following the OWASP Top 10 and OWASP API Security Top 10 risk lists. You get a report with reproduced findings, their business impact and the order of fixes, followed by a second check after the fixes; in Ukraine, Veiltrack is one of the companies that does this kind of website and API pentest.
A web application test means a check of your website, customer account area and API by a person who thinks like an attacker but works only within agreed limits. The API (the way applications exchange data) often matters more than the website itself: your mobile app, partner integrations and payments run through it. Below I explain the most important risks in plain words, what you need to provide, what is out of scope and what you get at the end.
In short
- The main risks are described in two lists by OWASP (an international non-profit community for application security): one for web applications and a separate one for APIs. [1] [2]
- The most common and most expensive problem is simple: a user sees or changes someone else's data. Only a person with several test accounts can find it.
- You provide the scope, two test accounts per role, the API documentation and written permission.
- The test does not touch third-party services without their owner's permission and does not guarantee that no bugs are left.
- A useful report explains business impact, shows how to reproduce every finding and is honest about what was not tested.
What gets tested: OWASP risks in plain words
The OWASP Top 10 (2021 edition) describes the ten most important risks for web applications, and the OWASP API Security Top 10 (2023) does the same for APIs. [1] [2] A new edition of the web list came out in 2025, and broken access control is again in first place. [3] For a business owner it is more useful to understand what can happen than to memorise numbers. Here are eight risks that most often matter for a website with a customer account area and an API.
| Risk | Example | How it is tested |
|---|---|---|
| Someone else's data by number (A01, API1) | A customer changes the order number in the address or API request and sees another customer's order with phone and address | Under one test account, the tester tries to open another account's orders, documents and profiles |
| Actions beyond the role (A01, API5) | A manager calls the administrator function "delete user" directly through the API, even without the button | Administrator requests are replayed under an account with fewer rights |
| Extra fields in requests and responses (API3) | The API returns a full customer record with passport details while the screen shows only the name; or a user adds an administrator role to their own profile | Full API responses are read, fields in requests are added and changed |
| Weak login and sessions (A07, API2) | Passwords can be guessed without limits, a password reset link works for a week, logging out does not end the session | Attempt limits, password reset, second login factor and session length are checked |
| Command injection (A03) | Someone types a piece of a database query into the search box and the site returns the list of all customers | Special characters and commands are inserted into every field and parameter, manually and with tools |
| Business logic flaws (A04, API6) | One promo code is applied ten times, a bot buys up all the tickets in a minute | Steps are tried out of order, repeated, with negative quantities and mass requests |
| Unsafe configuration (A05, API8) | An open admin panel, an error page showing a piece of code, a forgotten test copy of the API | Service addresses, error pages, headers and HTTPS settings are checked |
| Outdated components and forgotten API versions (A06, API9) | An old WordPress plugin with a known vulnerability; an old API version still works without the new checks | Versions are compared with known vulnerability databases, old and undocumented API addresses are looked for |
An automated scanner will not find most rows of this table: to a scanner, a page with someone else's order looks like a normal working page. How scanning differs from a manual test is explained in pentest vs vulnerability scan. OWASP describes the manual testing method in its testing guide. [4]
What you need to provide
The test goes faster and finds more when all of this is ready before the start:
- The scope. A list of domains, API addresses and environments: production or staging (a copy of the system for testing).
- Test accounts. Two for every role: customer, manager, administrator, partner. Without a second account of the same role, access to someone else's data cannot be checked.
- API documentation. An OpenAPI or Swagger description (a list of all requests in a standard format) or a Postman collection. Without it, part of the API stays unseen.
- Test data. Your payment provider's test cards, records without real personal data.
- The second login factor. How the tester will receive codes for the test accounts.
- Written permission and rules of work. Dates, hours, forbidden actions and a contact who can stop the test.
- A decision on the WAF (a filter for web requests). Whether to allowlist the testers' addresses, so the site is tested rather than the filter.
The full preparation list with a table of who does what is in how to prepare for a pentest.
What is out of scope
The limits matter as much as the scope. Usually these stay outside the test:
- denial of service attacks (DoS, overloading a service with requests);
- third-party services: payment provider, cloud CRM, email service, which cannot be tested without their owner's permission;
- phishing of employees and physical access to the office, which have separate formats;
- the mobile app, internal network and cloud settings, unless added to the scope separately;
- a full source code review, unless agreed.
The test shows the state of the system on the test date within the agreed limits. It does not guarantee that no bugs are left and does not replace secure development. The NCSC advises treating a pentest as a check that your processes for finding and fixing vulnerabilities work, not as the main way to find them. [5]
What you get
- A short summary for management: what was found, how it threatens the business, what to do first.
- Every finding separately: where it is, how to reproduce it step by step, evidence, impact, severity and how to fix it. Severity is often rated with CVSS (a severity scale from 0 to 10). [6]
- A list of what was and was not tested, so nobody assumes that untested parts are safe.
- An immediate message about anything critical, without waiting for the report.
- A retest (a second check after fixes), if it is part of the agreed scope. Agree on it before the start.
NIST describes these stages, from planning to reporting, in its technical guide to security testing. [7]
How to choose a provider
Ask three questions. How much time does a person spend testing by hand, and what exactly do they check under each role? Can you see an anonymised sample report? Is the retest included in the price? If the answer is only the name of a scanner, it is not a web application test. More questions and red flags are in how to choose a pentest company.
Checklist before a website and API test
Download the preparation checklist (PDF)PDF · A4
FAQ
Can you recommend a company in Ukraine that will check the security of a website and an API?
Look for a provider that tests manually under every role, works only with written permission, shows a sample report and does a retest. I run exactly this kind of test, details are on the pentest page.
How long does a website and API test take?
It depends on the number of roles, pages and API requests. For a small web application it usually takes from a week, for several systems longer. The timing and the price are fixed before the start, once the scope is agreed.
Can an automated scanner do the job?
No, if you have a customer account area or an API. A scanner finds outdated versions and unsafe settings, but does not see that one customer can open another customer's data. Regular scanning is useful between tests, not instead of them.
Is it safe to test a live website?
Yes, if the rules account for it: careful checks, agreed hours, a fresh backup and a person on call. More aggressive scenarios are better left for staging.
What is the OWASP Top 10 and is it still relevant?
It is a list of the most important risks for web applications from the non-profit OWASP community. The 2021 edition is still widely used, an updated one came out in 2025, and there is a separate 2023 list for APIs. [1] [2] [3]
References
- OWASP Top 10:2021 top10.owasp.org
- OWASP Top 10 API Security Risks 2023 api-security.owasp.org
- OWASP Top 10:2025 top10.owasp.org
- OWASP Web Security Testing Guide: Introduction wstg.owasp.org
- NCSC: Penetration testing ncsc.gov.uk
- FIRST: Common Vulnerability Scoring System first.org
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment csrc.nist.gov
