PHP security & upgrades
A lot of important systems in Pakistan still run on PHP written ten or fifteen years ago. Land records, payroll, admissions, procurement portals. They work, mostly. They also run on PHP versions that stopped getting security fixes years ago, and they tend to carry the same handful of flaws. We find those flaws, fix them in place, and leave you with a system your own team can keep running.
01In detail
What we usually find
Queries built by gluing strings together
User input pasted straight into SQL. It is still the most common way these systems get broken into, and the easiest to fix once you know where to look.
Upload forms that accept anything
A "CNIC scan" upload that will happily take a .php file, store it in a public folder and run it when someone visits the link.
PHP 5.6 or 7.x in production
PHP 5.6 stopped receiving security fixes in December 2018. PHP 7.4 followed in November 2022. Every new vulnerability since then stays open.
Passwords stored as MD5 or plain text
Sometimes in a column helpfully named password. One leaked backup and every account is exposed, including the ones people reuse elsewhere.
Sessions that never end
No CSRF tokens, no timeouts, admin rights checked on the menu but not on the action itself. Hide the button and the URL still works.
Secrets and backups in the web root
Database passwords in a committed config file. A file called db_backup_final2.sql that anyone can download if they guess the name.
What a first audit finds
A first pass on an older portal usually turns up a list like this. Most of it can be fixed without a rewrite and without taking the system offline.
Example output, not a real client.
02Process
How it runs
For government clients we work under NDA, on infrastructure you control if required, and we do not copy citizen data off your servers. Reports are written to be read by both the technical team and the officer who has to sign off on them.
Audit
1 – 3 weeks
We read the code, map every entry point and test a staging copy, both logged in and logged out. You get a written report ranked by risk, with proof for each finding.
Contain
Days, not weeks
The most dangerous issues get short-term fixes first: firewall rules, switching off dead endpoints, rotating leaked credentials. This stops the bleeding while proper fixes are written.
Remediate
Scoped per system
Proper fixes in the code. Parameterised queries, uploads checked and stored outside the web root, modern password hashing, CSRF tokens, permission checks on every action. Each fix is tested against the original proof.
Upgrade
Staged
Move to a supported PHP version (8.2 or later), update libraries, and tighten the server and database configuration. If a framework makes sense, we migrate one module at a time instead of rewriting everything.
Hand over
1 week
A full re-test, documentation of what changed and why, and a working session with your developers. We can stay on for maintenance or step away cleanly.
03Deliverables
What you get
- A risk-ranked audit report with evidence for every finding
- Patched source code in your repository, with a change log
- Hardened server, PHP and database configuration
- A re-test report confirming each issue is closed
- Handover notes and a session with your in-house team
Security checks
Six security checks before every launch.
Before anything goes live, we test it the way an attacker would, then write down what we found and how we fixed it. The same six checks run on every project, from a one-page website to a government portal.
- 01
Scan for known weaknesses
We check your code, the libraries it uses and the server for weaknesses attackers already know how to exploit.
OWASP Top 10 · CVE database
- 02
Try to break in
Our engineers attack it the way a real attacker would: logins, permissions, file uploads, pages that should be hidden.
OWASP ASVS
- 03
Check every public link
Every public page and address is crawled for files, folders and test pages that should never have been online.
OWASP Top 10
- 04
Look for malware
The code, the server and anything users can upload are checked for malware and hidden backdoors.
Before every launch
- 05
Try to trick the AI
For AI agents, we try to make them leak data, ignore their instructions or use access they should not have.
OWASP Top 10 for LLM Applications
- 06
Write it all down
Every finding, how we fixed it and the re-test that proves it, in a report your auditors can read.
ISO/IEC 27001-aligned process
Our process follows ISO/IEC 27001 controls. Prospiral is not ISO certified. VAPT means vulnerability assessment and penetration testing: the first two checks above.
05Questions
Questions we get asked
Almost never. Most of the risk sits in a small part of the code: login, uploads, search, anything that builds a query. Rewrites take a long time and bring new bugs of their own. We fix what is there and modernise in stages.
No. We work on a copy. Changes go live in small, scheduled releases, usually outside office hours, and every release has a rollback plan.
Yes, that describes most of the systems we see. The first job is usually getting the code into version control and setting up a staging copy. Documentation comes out of the audit as a side effect.
It depends on the size and how many user roles there are. A typical departmental portal takes one to two weeks. Larger systems take three or four. We give a fixed quote after a first look at the code.
Findings are mapped to the OWASP Top 10, and to the OWASP Application Security Verification Standard (ASVS) where a client needs a formal benchmark. That makes the report easier to use in audits and procurement files.
Yes. Some clients keep it on their own servers and call us for updates. Others move it to infrastructure we manage. Both are fine.
Start a conversation
Tell us what’s broken.Or what you want built.
Send a few lines about the system or the idea. One of the engineers who would actually do the work will reply, usually within a working day.