Not sure why it is downvoted as this is true. That said it is more to do with shared hosts culture choosing PHP than PHP itself. (They tend to support Ruby and Node but not as well)

PHP is also pretty easy to support for shared hosting, as what they essentially need is just an Apache module (+ nginx probably), some clever filesystem permissions and they're done. For node, Python, etc, you actually need to keep the application servers running, which has to stay running even when they're completely idle. So I think PHP is a natural choice for shared hosting for those reasons too.

This is exactly to the reason why PHP and before perl are successful in this space.

When you extrapolate that to modern tech, you could create a shared hoster with a configured reverse proxy and per customer docker images.

But that is so much expensive to build, operate and bill than an apache. And looks very close to AWS and friends.

I worked 10+ years in a web hosting company. PHP was chosen not because it was easy, it's because most people just use a CMS or something in PHP.

Keep a shared host secure, PHP or something else was not an easy task, most people installed unsecure versions or misconfigure something.

Also it was a pain to support PHP versions after EOL (yes, money), and multiple versions .

> For node, Python, etc, you actually need to keep the application servers running

Not with CGI.

You're technically right, however I imagine performance would be really poor, especially for Node. PHP has transparent opcache support and it's generally fairly efficient when run as Apache module, so it's usually preferred. You can of run PHP as CGI as well, however it's much slower.

Well it's not exactly secure by default. I was deploying an app to a new server and some bot grabbed my .env file before I finished the Apache config. Ultimately it's my own stupidity, but you don't have to worry about that with most other languages

Yes but that’s a framework specific issue. And usually your documentroot would point to a directory below that which holds .env. Oh the memories of apache and php.

Your comment makes no sense. How is that framework or PHP specific? Its simply a misconfiguration the server.

Some frameworks in the old days of PHP relied on .htaccess files to restrict access to unwanted files. Properly implemented frameworks would load everything from a directory above the documentroot to avoid these issues.

.htaccess is a config file type used by the Apache web server.

The server software reads the config file and then decides if the folder can be accessed externally or not.

It has nothing to do with PHP what framework or any other language you are running.

> .htaccess is a config file type used by the Apache web server.

Yup. That's why I am saying that in the past .htaccess used to be used, but modern php frameworks no longer rely on it. Poor phrasing on my end.

The mere concept of a "document root" is a problem though and a major footgun if you don't know what you're doing.

Every other language acts as its own web server which wouldn't even be capable of serving files even if you tried; the only thing it does is respond to web routes defined by the application.

This eliminates a whole chunk of security issues, from the one described above to malicious file uploads (PHP is probably the only language where a malicious file upload leads to RCE by default - other languages could happily accept and serve the malicious file back but wouldn't execute it).

> The mere concept of a "document root" is a problem though and a major footgun if you don't know what you're doing.

A non issue though after 2-3 days of working with this approach. All modern PHP frameworks have a so called front controller (an index.php file) that loads what it requires from ../ after, ideally, properly validating the request to avoid issues.

> A non issue though after 2-3 days of working with this approach.

Tell that to all the people with bleeding feet.

If you configure your webserver to serve the path above your website, is the webserver insecure?

So it wasn't the language, it was you? But it was the language?

Just like in C, every buffer overflow bug is the programmer’s fault.

You shouldn't deploy .env files to production. You should set the actual environment variables on production. .env files are intended for convenience on non-prod systems.

Agreed, but server frameworks shouldn't easily enable a foot gun that allows bots to have disk access to your host. Instead, only explicitly defined routes or resource files should be available.

If I had to guess, this person committed their .env file in some repo and pushed that up, and that become available because the server was misconfigured.

For other servers (such as, say, Jetty), config files like that won't get exposed like that unless you're very obviously placing your config files in a public resource folder.

If you apply the same level of thoughtlessness to any other framework, I assure you bots will grab your config also.

This, or variations, can happen with every kind of backend.

The only way to avoid to have the server open only to you till everything is tied down right and the backend is ready to face the world.

To rely upon being quicker on the draw than the bots is quite courageous.

That has nothing to do with PHP. If you have .env files in your document root PHP didn't put them there or require them. Every web site back-end can expose .git directories or .env files if not configured correctly -- that has nothing to do with PHP except that way more people use PHP out of the box and don't know about these issues or how to fix them. That's analogous to way more teenagers crashing cars than more experienced drivers, but that has nothing to do with the particular cars.

True. I setup a woocommerce site for someone 3 years ago, still makes around $1000 a month (pretty good for a small biz in India) and I just helped them downgrade from a $10 digitalocean VPS to a $3 cpanel hosting.

Classic php ecommmerce customer: miserable cheapskate that thinks saving 80 dollars a year is great, had my fair share of these

I wish cheap server hostings allowed loading php modules or at least had FFI module. Imagine thin php API-layer with rust-or-whatever-module under the hood. Easy deploying toys without need of VPS.

Doesn't cPanel supported several langauge including NodeJS runtime? I think most projects use composer or PHP packages.

Thanks to cPanel (written in Perl) this make life easier for developers to set up websites and skipped the ceremony but why is cPanel written in Perl instead of PHP?

But Go language has it own security implementations which are more secure and easier to deploy as a static binary. I did tried to write entire Go app using only built-in or some dev use Chi for routing. I didn't have to install Go runtime on VPS that you need for PHP.

Go built-in HTML template is quite secure, rare seen some fix to html/template make it easier to deploy new app, but my need evolve with Astro web framework that require Node.