How do I secure a purchased script before going live?
Treat the demo configuration as untrusted. Before launch: change every seeded admin password and key, turn debug mode off, keep secrets and uploads outside the public web root, force HTTPS, bind the database to localhost, and attempt one cross-customer data read yourself. Most breaches of self-hosted scripts come from default settings left in place, not from clever attacks.
Written by ZoopCoder, who build and sell SaaS source code. That makes us an interested party in this answer, so we have kept it to things you can verify yourself.
The numbers
Defaults first
Seeded logins and keys
Public demo credentials are known to everyone who read the sales page.
Debug off
The most common leak
Debug pages print paths, queries and sometimes secrets.
1 live test
Read another tenant's data
The only proof that isolation works is trying to break it.
The pre-launch checklist
Work down this list on the production server, not on your laptop. Each line is a setting you can verify in minutes.
| Area | Do this | How to confirm |
|---|---|---|
| Credentials | Replace every seeded admin account, API key, app secret and webhook secret | Log in with the demo credentials from the sales page: it must fail |
| Debug mode | Set the environment to production and debug to false | Trigger a deliberate 404 and 500; neither should show a stack trace |
| Web root | Point the server at the public folder only; keep .env, config and backups above it | Request /.env and /.git/config in a browser: both must return 403 or 404 |
| Transport | Valid TLS certificate, HTTP redirected to HTTPS, secure and HttpOnly session cookies | Check the cookie flags in the browser developer tools |
| Database | Listen on localhost only; a dedicated user with no admin rights on other databases | Attempt a connection to the database port from another machine: it must be refused |
| Uploads | Store outside the web root or block script execution in the upload folder | Upload a harmless .php or .js file and confirm it is not executed |
| Admin area | Unique URL or IP allow-list where possible, two-factor if the product supports it, rate-limited login | Submit ten wrong passwords in a row and confirm lockout or delay |
The one test worth doing yourself
Create two customer accounts in your own installation and try to read the first account's records while logged in as the second. Change an identifier in the address bar — an invoice number, a customer ID — and see whether the application checks ownership or simply returns whatever it is asked for.
- If anything from the first account appears, stop and do not launch. This class of flaw is the reason tenant isolation is worth verifying rather than trusting.
- Repeat the test on exports, file downloads and API endpoints, not just the pages you reach by clicking. Isolation is often correct in the interface and missing in a download link.
- Keep the OS and runtime patched. The script's own security is only half the surface; the PHP or Node version, the web server and the database all need updates. Budget the hours in the real running costs.
Where to go next
These pages carry the detail this answer summarises.
Frequently asked questions
Do I need a penetration test before launching?
Not for a first launch with a handful of customers, if the checklist above passes and you hold no unusually sensitive data. Commission one before you handle payments directly, health records, or enterprise customers whose contracts ask for it.
Who is responsible for security fixes in the script itself?
That depends on the update and support terms you agreed, which belong in writing before you pay — see <a href="/answers/do-i-get-updates-and-support/">updates and support after buying</a>. Because you hold the source, you can always patch a flaw yourself or pay someone to.
Is a hosted SaaS safer than self-hosting?
It moves the patching work to the vendor, which is a real advantage, and it moves your data and your uptime into their hands. Neither is automatically safer; the difference is who is responsible for the checklist.
What about backups as part of security?
They matter as much as any control above, since ransomware and a bad deploy are both recovered from the same copy. See <a href="/answers/how-to-back-up-and-restore-a-self-hosted-saas/">how to back up and restore a self-hosted SaaS</a>.
Get a quote or a guided demo
Tell us your use case and we'll send pricing, a live demo walkthrough and licensing options for SaaS source code. Usually a reply within one business day (IST).