Security concerns are always important when developing applications. With PHP I tend to find myself considering security more, not because there is anything wrong with PHP, but because PHP's simplicity is its own downfall; it is easy to put speed of development before security issues. However, over the years I have come to trust a few ideas and concepts of PHP as safe, and, while I do not in any way pretend that these are foolproof, they definately help me to keep in mind that security on the internet is somewhat problematic. Allow me to share these things with you.
POST, not GET
One security flaw is so easily overlooked: using POST to transfer information wherever possible, as opposed to using GET. GET is somewhat less secure than post simply because GET is easier to emulate than POST. I can just change the url in my browser to make it emulate a GET request. A POST request usually requires a form to be submitted, which is slightly harder--but not inpossible--to emulate. Specifically on things such as login forms and such, be very careful not to use things like "login.php?username=marc&password=hackme" wherever possible.
Validation is important, and validation is not just about checking if form values are null or not. Firstly, forms should be properly validated to check that all POSTED values are of the correct type, expected length, format, etc. But more than that, it is not only forms that need to be validated. Any data passed from one page to another should be checked for integrity, because that is exactly how security violations happen.
PHP Sessions are there for a reason, USE them. If you don't already know, the reason why GET, POST and SESSION exist is because PHP is not like a solid state, always-ready system like JAVA. I'm sure you are aware that PHP compiles at runtime, and only really executes for a few split seconds while the page is actually loading. Then it is dead, a closed thing that can only be accessed when the next page loads. So the creators of PHP had to devise a way of moving information between these pageload events, and that is where SESSION, GET and POST come in. It makes absolutely no sense at all that we have a page that only exists in one state for a fraction of a second before dying, so we can use these features to pass information from one pageload to the next, or even store data for a few hours--in a SESSION Array. Sure, you can use ajax to reload a certain part of a page, but all you are doing is loading a different page inside the one you have already loaded. There is no way you can actively revive the information in the page without these transfer systems that have been built into PHP--but it is also important to understand which to use when.
$_GET: Essentially this is for navigation, passing values through the url, such as simple information regarding the URL we are currently viewing.
$_POST: POST is the best way of submitting values from a form. POST values do NOT get carried along in the URL, so they are harder to see and catch. Generally you need a server-side script to catch the values, which makes it the preferred method of form submission, especially where sensitive information is being submitted.
$_SESSION: This is handy for keeping users logged in, as a primitive example. Setting a session variable and then checking that it is still there when the page reloads is quite a common practice. SESSIONS are somewhat more secure than GET and POST, but suffer from their own problems too. It is not a good idea, for example, to store credit card numbers in a SESSION ARRAY as this session array might only die a few hours after leaving the site.
$_COOKIE: Cookies have a different purpose. Usually these will be used for REMEMBER ME login scripts, for example. If you check the "remember me" feature on the Gmail login, the next time you come back to Gmail you are still logged in, right? That is because Gmail set a cookie on your browser, telling it to remember your login details. Cookies are bad for sensitive data, as they sit around on your browser just waiting to be exploited. The nice thing about cookies are that you can set what domain they work on, as well as how long they should take to expire. The bad thing is developers get lazy and let them live for 1000000000000000000 seconds and do not stipulate a domain that they are valid for. I sure hope that developer did not code my bank's website, because there are certainly going to be problems quite soon if he did.
Any other website with a script in them to read your browser's cookies will find my credit card information quite handy (OK, who am I trying to kid? I should say "Someone's Credit Card Information") simply because the guy who developed the website did not bother to specifiy the domain, thus the cookie is available to all domains. That is BAD. A footnote on cookies is that they are used to track your movements and search and browsing history by marketing companies and the major search engines. Clear your cookies in your browser OFTEN. It is in your best interest.
Hopefully you have learned that it is best to process the passing of information from one page to another by using a technique that best suites your needs. Basic navigation should use GET, while form submissions should use POST, and information for sustaining sessions should use SESSION. COOKIES are best used for domain sensitive information like REMEMBER ME.