When you're coding, do you actively think about your code might be exploited in ways it wasn't originally meant to do and thus gain access to protected information, run commands or something else you wouldn't want your users to do?
Kindof. Disclaimer: I'm a security guy ;)
So the way I work is that I have my threat model, which describes what kind of attacks by what kind of attackers are likely. That helps to work out the security requirements. When I'm actually coding, I do the usual "safe coding" practices like being careful that cursor variables are always within bounds, tainted input is sanitised, error conditions are handled. Then I go back to my threat model to see which modules are most likely to get targeted by attackers; those get some extra review.
I use industry-standard practices, like using SQL parameters. I use "safe" platforms, like the .NET Framework, and take advantage of security features like anti-forgery tokens in ASP.NET MVC. I don't write my own encryption algorithms, but I do understand what those encryptions provide in the way of security benefits, and when I need to use them to obtain those security benefits.
In short, I use best practices, but I don't develop my own security tools. I am not a security expert in that regard; I rely on other security experts, who have presumably already thought deeply about these issues, and have a clear understanding of the risks and benefits.
My fundamental approach to security, beyond simply using security tools, is to eliminate all possible input to the system except that which I am expecting. If I have a social security number field, the only characters that should actually show up are numeric digits and dashes, in a specific pattern.
I validate user input on both the client and the server.
I'm no security expert, but when I'm coding web applications I always assume that user input may contain all sorts of weirdness and should always be fully escaped and suchlike. Also, I'm careful in making Ajax calls back to the server to check that the user is logged in (if they should be for that particular event) and that they have the permissions to do whatever it is they're trying to do.
The codebase has a set of filters for inputs. I never check PHP's
$_POST arrays directly. Instead, I query them through a function
Request::get('parameter', 'filter') with filters such as
text, and a few others. (And
Request::post() for POST inputs, of course.)
Yes. When I worked on a multiplayer game, all were paranoid of exploits and ways to cheat. Cheating can destroy a game totally, not to mention any business models connected to selling in-game stuff. So security concerns and anti-tampering measures were very high on the agenda. I liked it very much. I have worked on others projects before where you had to feel guilty for working longer on the code just to assure it was secure.
Understand the general principles of security, (integrity, authentication, authority) and then read a few books about how people have been subverting these pillars of security for millennia and you will be about half way there.
Then read a few good books on design and testing strategies and you will learn how to design testability into your architecture.
Now we get to the point when I do think about security. I am thinking about how can I validate the data source, does it matter if the data is tampered with, who is the data source, how sure of that am i? how could it have been altered etc...
This affects the design. Config files may have key sections encrypted, or particular fields could be in clear text with an associated signature field. Things get more complex with internet facing services as you should expect a greater level of hostility there.
Then at testing, how do you test all this. What are your maximum data entries, what happens if you push the software beyond those limits, how does it handle it? What does it trust? how can you fake that trust?
I've dealt with enough hackers in the past to know that they're constantly trying to compromise any big site, and there are enough bots out there that even small sites aren't safe.
I try to think like a hacker all the time now, to the point where I sometimes worry my co-workers with casual comments on how systems we take for granted every day can be gamed.
It should be something any developer builds in to the process from the ground up to a greater or lesser degree, depending on application etc. Unfortunately, as devs don't tend to quote for security, buyers don't tend to think of it (I know, this is a bit catch-22, because if the buyers want the cheapest quote, it maybe won't include security)
As a developer you can gain a definite advantage if you are skilled in this area - I'm specifically thinking about banks and financial services, but other industries are also applicable. Currently they may budget 70 - 100k in training for a new graduate to be brought up to speed on processes, security and other specifics to that organisation. If you can save them 30k of that, that's a good CV plus!
In the UK, the Institute of Information Security Professionals, and in Scotland, the Centre of Excellence in Security and Cybercrime are working closely with Universities to help review course materials, provide guest lectures on real world implications of poor coding and facilitating summer placements (eg software developers placed into fraud divisions in law enforcement.) Most of the supporting organisations are doing this for free, as it has the potential to save them a large amount of money - sounds like value to me.
(disclaimer - I have been security guy for various global organisations)