Security for PHP pages (not databases)

Nice write-up, I agree pretty much across the board. We all season to taste.

For examples, in no order:

• Instead of assuring every folder has index.php, server-side you can handle that with the permissions set up for your site to disallow access if it isn't present. This is part of my initial Apache setup on a new site, along with my "get off my grass" removal of saving copyright images . Coming from days of 'ole, here and there, I too still include a blank index on entirely custom sites.
• On passwords, I just refuse to save them. I MD5 hash at absolutely minimum with the key safely tucked outside the servers permission area, but I just never save any clear text passwords.
• I typically use .htaccess mod_rewrite to change the URLs much the same way WP does. I re-write them to include nice titles but don't actually point to valid path structure. I totally agree that protecting any direct linking makes it really hard to figure out the system hierarchy or where to attempt attacks.
• I validate the URL params, including a length for each as well.
• Any time I can use a binary or encoded means of transferring from client to server, I do it. I got really used to AMF with Flash and the speed increases alone was worth it. Added in is at least a small layer of aggravation with people trying to parse your data as well as the ability to deserialize back to types like JSON can.
• Write a cookie, save it in local storage, remember it in a global, put it on a stickie on the clients system, but do NOT let them get through that contact form more than once or twice within a reasonable amount of delay. Even at that, especially with "share" links, don't offer someone an "email this subject to this person from your specified email address" on a platter or I assure you someone found themselves a fresh new script to spam from.
• Keep up to date with depreciation. Most people don't know basic mysql functions are starting to gain a movement to replace entirely with MySQLi or PDO. Imagine all the dead sites in the water..
• If you choose to use a CMS, greatly research it first. I have never had a single custom site hacked except for one silly contact form that was exposed (and fixed), back since Perl in the 90s. Yet the first time my designer tried to set up a fresh new WP site themselves, an attack message turned the entire site red bordered with a message from Syria, back when that was a tension. Luckily the site was not a clients, just testing templates. Be warned, understand what you install.
• Do your best to consider how the world is working. More emphasis on putting the computational burden on the client to manage data with sessionless, RESTful APIs on the business (server) side. Try to strike a nice balance so JavaScript frameworks, running single threaded, barely with full worker support, aren't blowing up mobile devices. Balance the load the server and client does to compliment your application based on your analytics.
• Ask someone to check your code! You'd be surprised how you can even go slow and low from the original 4's patterns all the way to modern day philosophies but actually end up developing code you can't read a year later. Definitely one of the worst days of any programmers life is reviewing code, asking "What the heck is this person doing here?!", and realizing it's your code..
• Flowchart (alright, I tried)
• When something doesn't make sense, step back, take a breather, take a walk, have a drink, do anything but spend "too much time" on a single problem. We all have a general sense, problem to problem, something isn't working right and it's taking too long to do. Time to back up and look at the big picture. Nope, the language (99.9%) isn't at fault, there is a problem. You will find it. Relax...

I think I could go on endlessly but it's hard not to flesh out each and every one with all sorts of real-life bonehead mistakes from myself as well as colleagues. Good times..