This article outlines the PHP_SELF attribute of the $_SERVER system information variable and why you should never, ever use it.
What is _$SERVER?
Check out our full article on $_SERVER here – but in short, it’s a variable containing an array with information about your PHP environment – including server and request details that are quite sensitive and shouldn’t be publicly accessible.
What is $_SERVER[‘PHP_SELF’] ?
$_SERVER[‘PHP_SELF’] contains the full path to the PHP script being executed, including any query parameters. This allows the party making the request to include arbitrary data. Displaying data from $_SERVER[‘PHP_SELF’] in a page would allow that party to inject code into your pages – a hack called (XSS) Cross Site Scripting.
XSS – Why Shouldn’t Use $_SERVER[‘PHP_SELF’] (Ever)?
As explained above, the value of $_SERVER[‘PHP_SELF’] is the path to the current PHP script – as sent by the party viewing the page. This means that they can append any data they like to this value, and it will be passed on to your script.
If you then display that value on a page – congratulations – you’ve given third parties an avenue for injecting their code into your page.
This is called XSS – a Cross Site Scripting hack.
With the ability to inject their own code into your page, a third party can now construct a malicious request to your website, which contains JavaScript of nefarious purposes, and spread it around the internet – turning your innocent web page into a vector for delivering viruses, or impersonating other pages, or even exploiting your own web server.
So don’t bloody use it!
What Should I Use Instead?
Some less informed online tutorials will suggest you use $_SERVER[‘PHP_SELF’] as the form action in HTML forms that you wish to submit to the current URL.
You can use:
$_SERVER['SCRIPT_NAME']
…safely instead. Ignore those tutorials – maybe they’re deliberately trying to add security flaws to websites. Who knows.
It’s also vital that you HTML encode any strings you will be displaying in a browser to mitigate any XSS attacks and ensure data that was not intended to be interpreted as HTML or JavaScript isn’t interpreted as HTML or JavaScript.
