Code security is inherent to the skill of a programmer. It's not in particular an issue with PHP, but rather the programmers that utilize PHP, arguably the most accessible programming language for creating web sites.
SQL injection and XSS are consequences of failing to sanitize input variables. PHP has made it much simpler since 5.0 through the introduction of filter routines and the PDO unified SQL driver to prevent malicious input, but at the end of the day it comes down to programmer skill.
Your best strategy to avoid exploitation is to program by contract. Parameters are expected to be within a certain range or be of a certain type; always test that these are the case. Method returns are expected to be of a particular type and fall within a particular range.
Writing clean, coherent code through design patterns (gang of 4 book) and having a decent IDE helps too. I've used varying IDEs over the years and love PHPStorm by far of all options.
edit: can't link inline until I have 5 posts, bummer
The most talked about are SQL, XSS, and CSRF, but poor programming can lead to multiple vulnerabilities. If you are not watching your routes or applying proper filters, someone can access information they shouldn't. Consider one user who makes a post in a forum, they can edit their post by visiting editPost.php?id=123. If you didn't have proper checks in place, anyone could visit that page and edit the content.
Utilizing routing filters which most modern frameworks provide, you can protect content and add User Access Controls.
Using PDO and prepared statements will likely reduce the places where SQL injection can take place. Most modern frameworks will use wrappers for PDO directly.
XSS can be avoiding by removing all tags on user input, or converting them to html_entities. Again, XSS can be a problem if users can store that content and allow others to view it. If a user can write content that can only be seen by them, then XSS is not going to be a problem. Ultimately though, converting HTML entities is a good idea in general.
CSRF can be avoided by using a hidden field that has a token that matches the user's session token. CSRF may or may not be a problem. It can be used maliciously to submit forms, attempt actions, brute force logins, etc. CSRF can prevent that, but may not be necessary on every form.
Session Hijacking is another issue, but may not appear often as it is more difficult, especially if you prevent XSS. To prevent this, you can store more information about a user and their session (IP, User Agent, Session ID) and then match them each request. If someone steals hijacks a session but is using a different browser, you will be able to figure it out and log that person out.
Ultimately, assume the user is never who they say they are. Assume they are going to spoof their Referrer, User Agent, Cookies, and anything else they can get their hands on. Never rely on the user to submit sensitive information directly to the server/database without authorization that they are who they say they are.
█ Managed Service Provider - www.OpticIP.com
█ Public & Private Cloud Solutions | SSD SANs | High IOP's | CDN Solutions
█ Phoenix/Chandler AZ Colocation | 48U Cabinets | Data Halls | TIA-942 Tier 4 Facility