What different types of security do there exist? Why and when should they be implemented?

Example: SQL Injection Prevention

  • 7
    I'd make this a bit more specific. As it is, it's difficult to answer. Perhaps "what security practices should you be aware of when writing applications/webapps/websites?" Sep 24, 2010 at 12:09

4 Answers 4


Preventing Buffer overflow

a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory. This is a special case of violation of memory safety.

Buffer overflows can be triggered by inputs that are designed to execute code, or alter the way the program operates. This may result in erratic program behavior, including memory access errors, incorrect results, a crash, or a breach of system security. Thus, they are the basis of many software vulnerabilities and can be maliciously exploited...

I cannot count exploits that are based on this.

  • 4
    But the solution's so easy: use a language that doesn't allow this. (That's what makes this exploit so tragic.) Sep 24, 2010 at 12:47
  • Easier said than done.
    – JeffO
    Sep 24, 2010 at 12:50
  • @Frank: This exploit can still happen in languages that don't have the constructs to allow it, but the VM/libraries have weaknesses. Dec 6, 2010 at 0:31
  • @JBRWilkinson that's a fair point. But what languages are those VMs written in? If your VM's written in a safe language, you're probably in a much stronger position. Your point still stands: your code might be immune, but you might use code that isn't. Dec 6, 2010 at 8:53

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.

Weak security

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

  1. Here's a useful selection of podcast episodes that discuss the topic: http://www.se-radio.net/?s=security&submit=Find
  2. Read up on some best-practices, for example http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=writing+secure+code&x=0&y=0
  3. Get your code security/penetration tested.
  4. Keep up-to-date with current threats and mitigation strategies through blogs and online articles: http://www.cert.org/sse/

Web applications:

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.