Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

Example: SQL Injection Prevention

share|improve this question

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.

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?" – Chinmay Kanchi Sep 24 '10 at 12:09
up vote 5 down vote accepted

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.

share|improve this answer
But the solution's so easy: use a language that doesn't allow this. (That's what makes this exploit so tragic.) – Frank Shearar Sep 24 '10 at 12:47
Easier said than done. – JeffO Sep 24 '10 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. – JBRWilkinson Dec 6 '10 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. – Frank Shearar Dec 6 '10 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:
  2. Read up on some best-practices, for example
  3. Get your code security/penetration tested.
  4. Keep up-to-date with current threats and mitigation strategies through blogs and online articles:
share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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