Web application and API security
We look for vulnerabilities that let an intruder read other people’s data, bypass payment or get administrator rights. We test by hand against OWASP, with and without an account.
- Request
GET /api/orders/10482Customer A - Response200 OK: customer B’s order with name, phone and addressLeak
- CauseThe API does not check who owns the orderOWASP API1
- FixCheck the object’s owner on the server when the request arrivesAdvice
IDOR rated CVSS 7.5, reproduced on a test environment
What we test
- Web applications
- Websites, customer portals, online banking, portals for clients and partners.
- APIs
- REST, GraphQL and SOAP: authorisation, object access, rate limiting.
- Mobile apps
- Android and iOS: on-device storage, server communication, protection against analysis.
- Source code
- Manual and automated code review, checks of dependencies and secrets in the repository.
Photographs
Photos: Sai Kiran Anagani, CC0; Christopher Bowns, CC BY-SA 2.0; Syced, CC0; Markus Spiske, CC0, Wikimedia Commons.
Testing models
Black box
We test as an outsider: no account and no information about the system.
Grey box
We get accounts for different roles and check whether one role can act as another.
White box
We get the source code and API documentation and find flaws that are not visible from outside.
How the work goes
- 01
Scope
We agree addresses, roles, test accounts and the testing window. We test on a copy or in production, as you choose.
- 02
Application map
We study functions, roles, input points and API calls.
- 03
Testing
We test against OWASP ASVS: authorisation, business logic, injections, file uploads and session handling.
- 04
Report
We describe vulnerabilities with requests, responses and reproduction steps. Developers get specific fixes.
- 05
Retest
After the fixes we retest the vulnerabilities we found.
What you get
- A list of vulnerabilities with CVSS scores and evidence.
- Recommendations for developers at the code and configuration level.
- A retest after the fixes.
- A report for management and auditors.
Questions
Ask your own questionCan you test a live website?
Yes, if we agree a testing window and leave out checks that change customer data. For deep checks a copy on a test environment suits better.
Do you need the source code?
Black and grey box testing needs no code. With the code, testing finds more in the same time, especially authorisation and business logic flaws.
Is the report suitable for a PCI DSS assessment?
The report describes the method, scope and results the way auditors expect. We agree the testing requirements with your auditor in advance.
Discuss your task
Describe the task and the timeline. We will reply, clarify the scope and propose a plan.
- Contract. We start with a contract and a non-disclosure agreement. The scope of work and the permissions are put in writing.
- Scope. Goals, systems, timing and emergency contacts are agreed before the work starts.
- Work. We keep you updated as the work goes and report critical findings at once.
- Report. We hand over a management report and a technical report with evidence and recommendations.
Or write to us: info@dozorsecurity.kz