I have created two pages (one straight HTML, the other PHP) to show an HTML file in the context of my server. The reason for this is simply to get access to / the styles in the CSS spreadsheets - not allowed when the page is opened straight from the file system.

These styles are saved in a meta field in the header and used for content editing.

Here's what I created:

<H1>Show Page</H1>
<form method="post" enctype="multipart/form-data" action="pageView.php">
<input type="file" name="file" />
<input type="submit" />



if (isset($_FILES['file']['tmp_name'])) {
//  echo "File submitted";
//  echo "File: " . $_REQUEST["file"];
  echo file_get_contents($_FILES['file']['tmp_name']);
} else {
  echo "No File Submitted";


It works, but I wonder: Is it safe? Are their any hacking vulnerabilities I should be aware of?

  • 1
    \$\begingroup\$ This question seems off topic for this site but it is not safe. At least it would be open to XSS. \$\endgroup\$ Feb 29 at 4:47
  • \$\begingroup\$ @YourCommonSense RE: XSS - but this is just self-hacking, or? Ultimately, the webpage is still running on the client computer, whether it comes from my server or their file system. \$\endgroup\$ Feb 29 at 14:48
  • \$\begingroup\$ Not sure what you mean. First you asked "what hacking vulnerabilities I should be aware of" and was provided with answer. Now it's whatever "self-hacking". So if "self-hacking" is not an issue, why did you ask? \$\endgroup\$ Feb 29 at 15:36
  • \$\begingroup\$ @YourCommonSense RE: why did you ask? I just want to know if there's anything I need to look out for and if the client could use this temporary hosting on the server (and the extra permissions to resources it comes with) to hack the server or others. \$\endgroup\$ Feb 29 at 15:57
  • \$\begingroup\$ As far as I can tell the code is safe: You send the file to the server and it echo's it back to the client. After that the file is eventually deleted. The code doesn't do much, and the same could be achieve client-side with a bit of Javascript. \$\endgroup\$ Feb 29 at 18:16

2 Answers 2


Is it safe?

I did some research and found This SO canonical post Security vulnerabilities with file_get_contents() using variable location). The OP of that question asked about passing a user-provided URL string to file_get_contents(). In the accepted answer is this final paragraph:

file_get_contents in itself appears safe, as it retrieves the URL and places it into a string. As long as you're not processing the string in any script engine or using is as any execution parameter you should be safe. file_get_contents can also be used to retrieve a local file, but if you validate that it is a valid internet facing HTTP URL as described above, this measure should prevent reading of local files should you decide to show the user what verification.txt contained in case of mismatch. In addition, if you were to display the contents of verification.txt anywhere on your site, you should make sure the output is properly encoded to prevent XSS.


As the PHP documentation describes:


The temporary filename of the file in which the uploaded file was stored on the server.


If one has access to/control over the php.ini file they can check the temp directory specified at directive upload_tmp_dir.

Thus the script above seems safe. There could be vulnerabilities in the future so it would be wise to stay informed about updates - e.g. from cvedetails.com, php.watch/news, etc.

Other Review Points

Eliminate else and one indentation level by exiting early

Instead of checking if $_FILES['file']['tmp_name'] is set before calling file_get_contents() the logic could be reversed to exit early using exit() or the simpler equivalent construct die(). With this approach there is no need for the else keyword. If the code was in a function it could throw an Exception which could be caught and handled by calling code appropriately.


if (!isset($_FILES['file']['tmp_name'])) {
  die "No File Submitted";

Closing PHP tag can be omitted

The PHP file appears to only contain PHP code (and nothing else like HTML). Per the PHP documentation for PHP Tags:

If a file contains only PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script.

screenshot of sample code in PHP documentation about closing tag


I wonder: Is it safe?

I will assume you serve such pages under https://example.com , that you set cookies, and that they store credentials for making security decisions. I expect that reflecting a web user's own text back to their browser is mostly safe. Publishing that text in the context of another user's browser definitely is not. OWASP describes this Cross Site Scripting behavior as an injection attack:

OWASP offers a variety of mitigation techniques.

Even if XSS is not a concern for your use case, there are still reasons you might wish to avoid the OP's proposed "no filtering" approach.

Suppose that victim.com publishes GIF images or similar assets, and has limited bandwidth resources. The OP code makes it very easy for a user to create a gallery.html file containing many <img src="https://victim.com/..."> tags, causing a browser to fetch and display many assets. When the victim organization investigates such resource usage, they may read the nginx webserver log and notice a very large number of "Referer: https://example.com/..." entries. Based on that they may choose impose a new policy which always rejects such asset requests, impacting the User Experience for your other users, even ones who make modest requests for just a single image asset.

Now of course, a client could have forged such "Referer:" headers even if you served 100% static content. But the OP script makes it very easy, and an admin who investigates the situation will immediately see a plausible story that explains high resource usage.

tl;dr: Displaying unfiltered user-submitted content could affect whether your site appears on certain Black Lists.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.