PPagepod
Menu

Security

Why static hosting is safer than shared PHP

2026-09-27

The dangerous part of free hosting is not the HTML. It is a programming language running inside the same machine as everyone else’s files.

What shared PHP actually shares

On a traditional shared host, your site and the site next door are directories on one operating system. PHP runs as a program on that system. A vulnerable plugin, an old file manager, or a script someone uploaded can often read files the control panel claimed were private. The attacker does not need a clever password if the interpreter can open the path.

Filters that block .php but allow .phtml, or that trust the last extension only, are a familiar way those panels fail. Pagepod rejects the executable extensions we know, including when they are hiding in the middle of the filename. That still would not be enough if a .php file that slipped through was executed. So it is not executed.

What the browser is allowed to do

A static site’s JavaScript runs for the visitor, on the origin of the subdomain. It can rewrite that page in their browser. It cannot ask the server to open /etc/passwd or the neighboring site, because those requests are not implemented. The server’s job is to return a file from one directory after the path has been checked.

The account cookie is not issued for subdomains. Even if a published page is malicious, it does not get the publisher session by default. That is a normal browser rule, and the cookie is set so the rule applies.

When PHP would be reasonable

PHP is reasonable when the code is yours, the machine is yours, and you accept the updates. It is a poor fit for strangers uploading code onto a free shared disk. A later version of Pagepod can run PHP only if each site has a separate container and filesystem. Until then, static hosting is the whole offer, and it is the safer one.

Pagepod’s isolation rules