Free

Free coded apps to suit all. No sign up, no email, usable offline, updates when I can, feedback welcome. Send feedback

Thinking

Is a PHP website made by Base secure?

The PHP site Base by Zaweba exports uses prepared statements, CSRF tokens, escaped output, hashed passwords and limits on failed logins.

Is a PHP website made by Base secure?

It is built with the standard defences a PHP site should have. The website that Base by Zaweba exports uses prepared statements for every database query, a CSRF token on every form, escaped output, hashed passwords and a limit on failed logins. Its uploads are size-limited and pictures are checked to be real images. How secure it is in practice also depends on your host and on who you give logins to.

Here is what each of those protections does, in plain terms, and what remains your job.

What the site protects against

Prepared statements. The site talks to MySQL or MariaDB through PDO with prepared statements, so text typed into a search box or form is treated as data, never as part of a database command. That closes off SQL injection, one of the oldest ways in.

CSRF tokens. Every form carries a token, so another website can't trick a logged-in person's browser into submitting changes behind their back.

Escaped output. Whatever is stored in the database is escaped before it is shown on a page, so a record containing script code displays as text rather than running.

Hashed passwords. Logins use PHP's password_hash, so the database never holds passwords as readable text.

Login throttling. After 10 failed attempts from one address in 15 minutes, further attempts are refused for a while, which stops someone guessing passwords at speed.

The session cookie is HttpOnly and SameSite, which keeps it out of reach of page scripts and other sites. Uploads are limited in size, and pictures are checked to be real PNG, JPEG, GIF or WebP files rather than something renamed.

What the site deliberately leaves out

Buttons and scripts stay in the desktop app. Action queries, the ones that update, append or delete records in bulk, are not exported either. The website gets standard pages instead: a list, view, add, edit and delete page for each table (delete asks first), plus read-only pages for saved queries and reports.

Your validation rules, value lists and unique keys go with the database as constraints in MySQL or MariaDB, so the browser can't put in values the desktop would refuse.

One kind of user

The exported site has one kind of user: everyone who logs in can change everything. That is simple, and fine for a small team who all do the same job. It is not suitable if some people should only read, or only see their own records. Give logins only to people you would trust with the whole database.

Your part of the job

The installation steps matter. The README that comes with the export walks through them: create a database on your host, import the SQL, fill in lan_data.php with the database details, upload the site folder, run setup.php to create the first login, and then delete setup.php. That last step is important, so don't skip it.

Use a host that serves the site over HTTPS, so logins and records aren't sent in plain text, and keep its PHP up to date (the site needs PHP 8.2). Choose strong passwords. When you export again after changing the design, Base keeps your filled-in lan_data.php, so the database details aren't lost.

Trying it safely first

Before putting anything online, you can run the site on your own PC with Server by Zaweba, which Base offers to open after exporting if it is installed. That is a good place to check the pages, the logins and the rules with test records. Base by Zaweba's export is a sound, conventional starting point, and the rest is ordinary good practice on the hosting side.