Аннотация

There are many ways to start a guide or book on PHP Security. Unfortunately, I haven’t read anyof them, so I have to make this up as I go along. So let’s start at the beginning and hopefully it willmake sense.If you consider a web application that has been pushed online by Company X, you can assume thatthere are many components under the boot that, if hacked, could cause significant damage. Thatdamage may include:1. Damage to users - which can include the exposure of emails, passwords, personal identitydata, credit card details, business secrets, family and friend contacts, transaction history, andthe revelation that someone called their dog Sparkles. Such information damages the user(person or business). Damage can also arise from the web application misusing such data orby playing host to anything that takes advantage of user trust in the application.2. Damage to Company X - due to user damage, loss of good reputation, the need to compensatevictims and partners, the cost of any business data loss, infrastructure and other costs toimprove security and cleanup the aftermath, travel costs for when employees end up in frontof regulators, golden handshakes to the departing CIO, and so on.I’ll stick with those two because they capture a lot of what web application security should prevent.As every target of a serious security breach will quickly note in their press releases and websites:Security is very important to them and take it very seriously. Taking this sentiment to heart beforeyou learn it the hard way is recommended.Despite this, security is also very much an afterthought. Concerns such as having a working appli-cation which meets the needs of users within an acceptable budget and timeframe take precedence.It’s an understandable set of priorities, however we can’t ignore security forever and it’s often farbetter to keep it upfront in your mind when building applications so that we can include securitydefenses during development while change is cheap.