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.
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 userecho "qualquer coisa"
like text, like when you open a PHP in a notepad.– Inkeliz