One number
A customer logs in to a new portal and opens their invoice.
They notice the document number in the page address and try changing it.
The application displays another customer’s invoice.
They did not crack a passwordIn general, a password is an arbitrary string of characters including letters, digits, or other symb... More. They did not bypass the loginThe information used to log in to a service, usually username, email, password, code, or security ke... More. They did not use any special tool.
They changed one number.
The loginThe information used to log in to a service, usually username, email, password, code, or security ke... More still works. Invoices load correctly. The application passed its standard tests.
The application verified that the user was logged in. It did not verify whether that user was allowed to view this particular document.
The feature worked.
Just not securely.
It passed acceptance testing
During application handover, the expected workflow is usually tested.
A user logs in, completes a form, submits an order or downloads a document. An administrator updates a record. The data is saved and the necessary information is passed to the next system or person.
This type of testing answers an important question:
Does the application do what we ordered?
It does not automatically answer another one:
What does the application allow when someone uses it differently from the expected workflow?
Can a regular user open someone else’s document? Can they access a function intended for an administrator? Can they see information that does not belong to them? Can they skip part of the process?
A security issue does not have to cause the application to crash or display an error.
Quite the opposite. The application may process the request without any problem.
Just for the wrong user or with someone else’s data.
Are you accepting or launching a web application?
Send a brief description of the application, its user types and the planned handover date. I will tell you whether it fits the Web Application Security Review or needs a Custom Penetration Test.
When development speeds up
AI toolsThe ability of an AI system to use external tools, services or functions. More can significantly speed up web application development.
They can help create loginThe information used to log in to a service, usually username, email, password, code, or security ke... More flows, administration interfaces, forms, file uploads, exports and integrations with other systems. A working version can appear very quickly.
That is not a problem by itself.
The problem starts when development speed is mistaken for verification of the result.
Every new feature introduces decisions the application must make correctly:
- Who is allowed to open this page?
- Who owns this document?
- Who is allowed to modify the record?
- What can a regular user do, and what is restricted to an administrator?
- Which data is the application allowed to display?
AI can create the feature. Someone still needs to verify who can use it and what it allows them to access.
The same applies to conventional development. With applications built or significantly accelerated using AI, however, it is easy to skip the security review because the working result looks finished very early.
A different perspective
A security finding does not automatically mean the vendor or developer did a poor job.
The development team must deliver the agreed features, connect the individual components, fix bugs and ensure that the application works as a whole.
Security should be part of good development. An independent review still serves a different purpose.
A developer may ask:
Can the customer view their invoice?
A security review adds a second question:
Can they also view someone else’s invoice?
It does not test only the expected workflow. It also checks modified identifiers, bypassed roles, access to other users’ data and other situations that may not be covered by standard acceptance testing.
Development testing and an independent security review are not competing activities.
They answer different questions.
While there is still time
The best time for an independent review is before final acceptance, launch or final payment for the project.
The vendor still has the application in context. The development team is available. Documentation and the test environment are close at hand.
Problems can be addressed while the cooperation is still active, rather than after customers are already using the application and the original team has moved on to another project.
The company also receives a practical basis for deciding:
- what needs to be fixed before launch;
- which issues have the greatest practical impact;
- what can be addressed later;
- whether a limited security review is enough;
- or whether the project needs a broader penetration test.
A review can also be useful for an application that is already running. Handover is nevertheless a natural point at which the company accepts responsibility for the system, its users and its data.
It is better to know what you are actually accepting.
Not a stamp of approval
The purpose of a security review is not to certify that an application is secure once and for all.
No honest test can provide such a guarantee. Every assessment takes place at a particular time and within a predefined scope.
The result should not be an unexplained automated list of technical abbreviations either.
The client needs to know:
- what was found;
- what practical impact the issue may have;
- how serious it is;
- how the developer can verify it;
- what should be fixed first.
The deliverable should be a prioritised report with specific remediation recommendations.
Not a general warning. A practical basis for remediation and further decisions.
Security review or penetration test?
For one smaller web application, a Web Application Security ReviewA practical review of a web app focused on common flaws, login, permissions, sessions, and data hand... More may be the appropriate option.
It has a predefined scope and focuses on the most important parts of the application: loginThe information used to log in to a service, usually username, email, password, code, or security ke... More, user roles, permissions, main workflows, handling of non-public data, forms, file uploads and APIs.
The deliverable includes a prioritised report, remediation recommendations and a final consultation.
The price is CZK 35,000 for a predefined scope.
For a larger or more sensitive application, a Custom Penetration Test is usually a better fit. This typically includes systems with more user roles, multiple environments, a larger API, more integrations or specific risk scenarios.
A custom penetration test also has a clearly agreed scope. It is defined individually according to the application, the objective of the test and the required depth.
The price is determined after a short scoping process.
Before you sign off
A successful handover confirms that the application does what was ordered.
It does not automatically confirm who can use its features to access particular accounts, documents and data.
AI can significantly accelerate development. It cannot replace an independent review of the result.
Before final acceptance, it therefore makes sense to ask one more question:
Has anyone tried using the application differently from the documented workflow?
Send a brief description of the application, its user types, environments and planned handover date.
Based on the scope, I will recommend either a Web Application Security Review or a Custom Penetration Test. If neither option is appropriate for the project, I will tell you.
Send a brief description of the application
