Building secure web application - my two pennies

I recently ran into discussion about PHP application security. The main question was:

Can anyone tell what security issues should I consider to make it (a PHP+MySQL+Ext JS application) a secure application.

My first tough was to send a link to Owasp TOP-10. But that would not be enough - If one needs to ask such broad question on Linked In then he/she is not ready to make a secure web application. Making a web application secure is not a topic that can be inclusively answered with a single forum- (nor blog)-post. There are quite meny books written on the subject.

But never the less i'll try to give my contribution on the matter and write down few (as simple as possible) rules that anyone even considering making a web application should obey.

Treat every request as it came from your worst enemy

... and it is trying to break your application. Validate every single input of the request before using it anywhere. If possible, build your software in a way that you cannot bypass the validation in your code even if you wanted to. If some input needs to accept pretty much everything then make a rule that says "pretty much everything allowed" - this shows that you have even thought about input sanitation. Finding the right balance between too tight and loose validation rules is the hard part. Owasp TOP-1 - Injection.

Escape every single output

... as close to the actual outputting as possible. It doesn't really matter where the input came from - GET-parameter, a form the user just posted, database or some exotic setting file. It might have been compromised and if it has, you do not want output it in a way that it would be executed in users browser. Because that is the way to Owasp TOP-2 - Cross-Site Scripting.

Do not let anyone access any restricted data

... unless they're specifically allowed to do so. Whenever anyone asks for any non-public data, check that the user has rights to access it. And if not, the safest way to handle the situation is to give a 404. This way you don't tell that the object tried to access actually exists - but the user doesn't have rights to access it. Owasp TOP-4 - Insecure Direct Object References.

Use random tokens to every state-changing request

... to make sure that the request came from your UI - not some malicious site the logged in user happens to be browsing. Simply put: store a random string to session-data and when the application receives request to state-changing action, make sure that it is the same that you have stored in session. The token doesn't need to be unique for every request, but it needs to be unique for that session. When encountering missing or inaccurate token the failed request should be logged as it might be Owasp TOP-5 - Cross-Site Request Forgery. Also reset the session token - cannot brute-force something that is constantly changing, can you?

Do not take any redirect parameters directly from the URL

... because those do not belong there! If you do then anyone can make a link that starts with your domain but lands somewhere totally different - like their phishing site that looks exactly the same as yours. And *puf* the hackers now have valid credentials to your application. Owasp TOP-10 - Unvalidated Redirects and Forwards.

And by mother of a supernatural intelligence:

Never ever store the passwords in plain text!

I hope that I don't need to tell you why.