What different types of security do there exist? Why and when should they be implemented?
Example: SQL Injection Prevention
closed as too broad by gnat, Kilian Foth, BЈовић, Bart van Ingen Schenau, GlenH7 Jul 23 '13 at 11:12
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.
Preventing Buffer overflow
I cannot count exploits that are based on this.
I am no expert, but in my experience, there are several well-known attack vectors for systems:
Unvalidated user data
This is the classic buffer-overrun, SQL injection, drive-by-download mechanism and is caused by insufficient planning or education on secure coding practices. It is important to ensure developers understand how any insecure code can be leveraged to exploit a zero-day attack on a computer. Just because your website doesn't do anything particularly secret/important, doesn't mean that getting root access on your webserver can't harm the other parts of the organisation.
This can be a blend of poor security infrastructure, policy or just bad passwords. The worlds most popular password is 'password1' since most email providers started insisting on alpha-numeric passwords - previously it was 'password'. If a dictionary-based attack can guess a users' password, the policy was insufficient.
Some enterprising programmers leave quick-access backdoors in code in case they need to jump in and 'fix' the system. If you have any of these, deliberate or otherwise, your system is a ticking time-bomb.
What to do about it
Based on the number of attacks - see stats by Verizon, OWASP, WHID and others - the single biggest thing you can do to improve the security of a web application is implement solid input validation. Do not trust anything the client/browser sends you. This will pretty much sort your SQL injection issue, and help out in a number of other areas including field/buffer overflow.
It depends completely on the type of app, what a potential exploit might accomplish and the expected environment.
If you are running in an environment assumed to be safe then you could argue few to none.
If you are writing a web app that is publicly exposed, or an app that involves a publicly exposed API you would have to think through the likely scenarios like defacement, false submissions, authentication exploits, getting access to data not belonging to you, etc.
If you are building an app that stores data locally you might need to be concerned with the security of that data, keeping it separate between users on a multi-user system, etc.
IMHO there are not any security concerns that are ALWAYS applicable in every situation.