It's the most insecure code in the world
Tags: php, webdev
Published: 2021-12-19 08:33:05

>**Just the Gist**  
>A not uncommon criticism of PHP is that it lacks in security. The sad part is, we can't argue against it. It's too broad of a criticism which can be leveraged against most languages, as most have some way a secret can be leaked. Modern PHP and modern coding practices exists to mitigate this. But today, we are going to take a look at one very basic security flaw example, and a way we could mitigate it. It's what could happen if we don't run a web server but still have our php-files public.

Say that we have an `index.php` located in a public-folder. This file is protecting the identity of the secret santa until Christmas Day. It may look like this:  
```php
<?php 

define('SECRET_SANTA', "Olaf ⛄");

?>

<!DOCTYPE html>
<html lang="en">
<body>
    <h1>The Secret Santa is a secret!</h1>
    <p>You have to wait until Christmas Day to know who it is.</p>

    <?php 

    $today = new DateTime("now");
    $christmas = new DateTime("2021-12-25");

    if ($today >= $christmas) {
        echo "<p>The Secret Santa is " . SECRET_SANTA . "!</p>";
    } else {
        echo "<p>The Secret Santa is still a secret.</p>";
    }

    ?>
</body>
</html>
```
As long as we have a web server service active (such as Apache), this will be interpreted correctly and we would have the following output:  
![The website display that the secret santa is still a secret.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0f8ku1k3rvbzmskknbxz.png)

But what would happen if the service was down and we had visitors to the website? Instead of parsing the PHP file and rendering the correct output, we would serve the file as simple text. All our code would be visible and any one could see that it's Olaf! 😱  
![The website display all the code and any one can see that Olaf is the secret santa.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e1u665j2xs5wtbsgyd2u.png)
  
So how could we protect ourselves from this happening? We could move our secrets out of the public folder (or the web-root) and into a folder that is not accessible by visitors. Say that we have the following structure:  
```
/
  |-- public-folder
  |   |-- index.php
  |   
  |-- private-folder
      |-- SecretSanta.php
```
Our visitors would be unable to see the contents of the `SecretSanta.php` file, but they would be able to see the `index.php` file. So here's how we could do this.  
**SecretSanta.php**
```php
<?php

class SecretSanta 
{
    private const SECRET_SANTA = 'Olaf ⛄';

    public static function getSecretSanta(): bool|string
    {
        if ((new DateTime("now")) >= new DateTime("2021-12-25")) {
            return self::SECRET_SANTA;
        } else {
            return false;
        }
    }
}
```

This class declares a constant with the identity of the Secret Santa. It's private so no other file has access to it. We must use the static function `getSecretSanta()` to access the secret santa. This function will return the secret santa if it's on or after Christmas Day, otherwise it will return `false`. 
 
Going back to the `index.php` file, we can now get the secret santa by calling the static function on the class (`SecretSanta::getSecretSanta()`):  
```php
<?php 

require('../private/SecretSanta.php');

?>

<!DOCTYPE html>
<html lang="en">
<body>
    <h1>The Secret Santa is a secret!</h1>
    <p>You have to wait until Christmas Day to know who it is.</p>

    <?php 
    if (SecretSanta::getSecretSanta()) {
        echo "<p>The Secret Santa is " . SecretSanta::getSecretSanta() . "!</p>";
    } else {
        echo "<p>The Secret Santa is still a secret.</p>";
    }

    ?>
</body>
</html>
```

We would still get the same output as before when the web server service is running, but now we can see that the secret santa is not visible to the public if the service is down. This is but one example of how it may be a good idea to have your application logic and secrets outside of the public folder. 

>There is so much more to keep track of when it comes to security. This article hasn't covered even a fraction of it. And many of the issues are not specific to PHP. There are Cross Origin Resource Forgery (CSRF) attacks, SQL Injection, Cross Site Scripting (XSS), and many more. 


## What about you?
Perhaps you have some good insight into good security practices within the PHP ecosystem, please share! Have you encountered projects with bad security? What are your best security recommendations to web developers building their first couple of PHP projects? Comment below and let us know what you think ✍

## Further Reading
* PHP Manual on Security: https://www.php.net/manual/en/security.php
* Zend on how to handle security risks: https://www.zend.com/blog/managing-security-risks-php-engine-and-web-applications