Show HTML via PHP or not?

Asked

Viewed 966 times

1

In fact, it’s very common to see all the code HTML escaped inside the tags PHP.

"For printing large blocks of text, going out of PHP’s interpretation mode is usually more efficient than sending all the text through echo or print functions." Escaping the HTML

Leaving aside the work of escaping all the code HTML and the processing cost (since it will call the PHP interpreter to display the HTML), as the issue of security?

See the following:

Code HTML outside the tags of PHP:

<?php
    if( $a == $b ) { ?>
        <!-- CÓDIGO HTML -->
<?php
    }
?>

Code HTML within the tags of PHP, shown with echo:

<?php
    if( $a == $b ) {
        echo "<!-- CÓDIGO HTML -->";
    }
?>

Runs some risk of PHP interpreter stop working unexpectedly and code out of tags PHP be exposed to the user, even if by the source code (via browser)?

  • 1

    If the PHP interpreter stops working it will expose all the PHP code to the client, even for this reason it is recommended to keep codes such as settings (and containing passwords/keys) in places not accessible to the public. Anyway, if the interpreter stops working have echo or is not the least, if it stops it will deliver to the user echo "qualquer coisa"like text, like when you open a PHP in a notepad.

1 answer

2


To be honest, neither is good practice.

Both do basically the same thing, the performance gain is not so great as to justify this.

But the ideal is not to use that kind of approach... If you want to create a dynamic page, use an API that returns the data you need and do it via Javascript.

But to answer your question, the only way would be if apache stopped working, but then your page wouldn’t even be served via web.

But if at some point only the compiler appeared, its source code would rather be shown to the end user.

Editing: Adding new content


In the case of back-end security, in addition to the fact that render the page and send it based on http templates it’s not safe, you will need to keep an eye on some things that may actually impact your website if your compiler stops working.

First: Safety of the environment


Never, ever, ever, ever let users, passwords and hosts of hardcoded databases in the application, in short, do not define a constant, or anything that is visible within your source code that shows how to access your databases.

In return, make a file env.ini (or .env.ini or as you wish to call it) and read the settings of this file. The template .ini is a fairly old and accepted standard in the community that can be parsed by php natively and transformed into an array if you follow the correct syntax:

[database]
user=seuuser
senha=suasenha
host=seuhost

See more about ini files in the links below:

And how to open and parse by PHP:

Second: Source code security


It is very unlikely that the PHP compiler will stop working out of the blue and the web server (IIS, apache or Nginx) will continue working, because both are very connected to each other and, At the end of the day, the PHP compiler is just a program that runs over a file that causes it to be modified. For this the webservers perform the step of running the compiler on each file that is served, so I said that it is very difficult for your source code to appear to the end user (in 7 years of PHP experience, this never happened to me at least)but as we always have the possibility of that 1% there are some practices:

  • Your source code should not expose all logic in a single file:
    • Monolithic codes tend to be much easier to decipher if read in sequence, so try to break into several components, because if one of them appears on the screen, the user will not find out how the others behave
  • Avoid any types of sensitive or sensitive information directly in the source code
    • As I said before, this doesn’t just apply to passwords and database information, remove all sensitive data and store in files out of reach of the webserver itself

Completion

I would not use the rendering of this template, but if it is not an option to remove it, I believe you would be subject to the display of the source code in very rare situations, but still possible, what you can do is basically take steps to make it not a problem.

Your source code should not be the complete description of your product, but rather parts independent of the overall logic of what it should do, so that a person would need to put all those parts together to contain something cohesive and that actually makes sense.

  • So, as mentioned *"Leaving aside the work of escaping all the HTML code and the processing cost (since it will call the PHP interpreter to display the HTML), what about the security issue?" *, my concern is with security. It wouldn’t be cool for the server to hand-deliver my source code (PHP) to the user. Especially if this source code includes the connection to the database. Ever wondered? Incidentally, use IIS of Windows Server 2008 R2 running PHP’s CGI module.

  • 1

    But there is the security, if your compiler stops working it will deliver your source code to the user. In order for you not to have this problem of database connection, good security practices ask you to read a local configuration file (not accessible), I will edit the better answer

  • @Lipespry see if this satisfies most of your problem

  • 1

    Following your idea of INI archive, I created an environment variable in the handler itself Fastcgi with the path of my configuration file within the server, leaving it totally separate from the site files. In PHP, access this variable with $_SERVER['ARQUIVO_CONFIGURACAO'] and I care about $conf = parse_ini_file( $_SERVER['ARQUIVO_CONFIGURACAO'], 1 );. Thanks for the support, @Khaosdoctor!

Browser other questions tagged

You are not signed in. Login or sign up in order to post.