In short: A penetration test of your PHP application shows which weaknesses an attacker could actually exploit before anyone does. Together with specialised partners, we test the application and server within a scope agreed in writing and deliver a report with prioritised measures. After the fixes, we check in a retest whether the vulnerabilities are closed.
Why a penetration test makes sense for PHP applications
PHP2Shell has shown that even the foundation of an application, PHP itself, can contain a critical vulnerability. Most break-ins into PHP applications, however, go through known weaknesses in your own code or in the configuration: SQL injection, cross-site scripting, insecure file uploads, weak sessions, outdated dependencies or open admin areas. The OWASP Top 10 summarise these categories.
An independent outside view finds what is overlooked in everyday work. For management and oversight, it provides a reliable basis for assessing risks and spending budget in a targeted way. For developers, it is a concrete to-do list.
Audit or penetration test: which suits you?
| Form | What is tested | Suitable if |
|---|---|---|
| Configuration audit | server, PHP, web server, access, backups | you want to know the state of the infrastructure |
| Code review | application source code with full insight | you have custom developments or major customisations |
| Black-box penetration test | application from the outside without prior knowledge | you want to see the view of an external attacker |
| Grey-/white-box penetration test | application with test accounts or code | you want to find as much as possible in limited time |
A combination often makes sense, for example a configuration audit of the server together with a grey-box test of the application. A pure black-box test looks realistic but spends a lot of time on exploration. With test accounts and insight into the structure, testers usually find more weaknesses in the same time.
Besides the application, it is worth looking at the environment: which PHP version is running, are admin interfaces publicly reachable, are backups stored in the web directory, are dependencies up to date? We include such points in the audit because in practice they often weigh more heavily than an individual error in the code.
When is the right time for a test?
A penetration test brings the most when it takes place at a sensible point in the application's lifecycle. Typical occasions are:
- before launch of a new application, shop or customer portal
- after major changes, such as new payment methods, interfaces or login procedures
- after an incident, when cleanup and hardening are complete and you want an independent check
- at regular intervals, if customers, partners or your risk management require it
A test makes little sense as long as known vulnerabilities are open. Anyone still running unpatched PHP versions should first establish the baseline. Otherwise you pay for a test to confirm what is already known.
How does PHP SOS help?
- Define the scope: We clarify with you which applications, servers and functions are tested, which type of test fits and what is explicitly excluded. The result is a written engagement with time window and contact persons.
- Prepare: Test accounts, access to the test environment and a current backup are provided. Your hosting provider is informed if needed so that the test is not blocked as a real attack.
- Test: Our specialised partners test using recognised methods, among others along the OWASP categories. We report critical findings immediately, not only in the final report.
- Report: You receive a report with a management summary and a technical part.
- Retest: After the fixes, we test the vulnerabilities found again and confirm which are closed.
Many findings can be avoided in advance. The guides on SQL injection in PHP, secure file uploads and sessions in PHP help developers prepare.
What you get and what we need
The report contains every vulnerability found with a description, the affected location, a risk rating and a concrete recommendation for fixing it. A summary for management classifies the results without jargon. After the retest, you receive a confirmation of which items have been fixed. Attack tools or executable exploits are not part of the report.
We need from you:
- written permission from the authorised person for each system to be tested, even if it is hosted by a provider
- test accounts with the roles to be tested
- a test environment or permission to test in the live environment within a time window
- a technical contact person during the test
- for a code review: access to the repository
What we do not promise
A penetration test does not find every vulnerability. It is a snapshot within the agreed scope; new functions or new vulnerabilities in dependencies can produce a different picture tomorrow. We do not cite certificates or seals that we do not hold, and we do not issue attestations that replace legal obligations. Whether a test meets your obligations under NIS2, for example, is something you clarify with your legal and compliance specialists.
On request, we carry out the fixing of the findings ourselves or together with your agency. For server and PHP configuration, server hardening is a good fit.
Frequently asked questions
What is the difference between a security audit and a penetration test?
An audit checks configuration, processes and code against requirements and experience, often with insight into the systems. A penetration test deliberately tries, with your permission, to exploit weaknesses in order to show their actual impact. The two complement each other.
Is a penetration test of my PHP application dangerous?
A test can put load on systems or change data. That is why scope, time window and limits are set in writing beforehand, and we recommend using a test environment where possible. A current backup is always part of it.
Does a penetration test find all security vulnerabilities?
No. A test shows the weaknesses found within the agreed scope and period. It is a snapshot and lowers the risk, but does not prove that no further vulnerabilities exist.
Does a penetration test help with NIS2?
Regular testing of security measures is a common building block for meeting risk management obligations. Which requirements apply to your company specifically is something you should clarify with legal and compliance specialists.