Questions You Should be Asking Your Application Developer Candidates

Old habits die hard. The following questions will help you avoid hiring developers with bad habits. Developers with bad habits are prone to baking in those habits into the overall application architecture. There are two fronts in the war of protecting your applications. The first front is reactive. It is your code maintainers patching flaws in old code bases. The second front is happening right now. All over the world. The tap, tap, tappity-tap of a developer's programming insecure code into your application!

An application developer does not need to be an information security guru to be a secure programmer. They should, however, be aware of and know the best practices for common flaws.

1.) What is SQL Injection (and how do you prevent it)?

Application developers are the gatekeepers to your most precious resource, information. You want to make sure your gatekeeper knows how the gate works. This way they use the actual gate instead of blowing a huge hole in the fence.

• Zero points if not capable of defining SQL Injection.
• One point if they use the word "parameterize" or "ORM".
• Negative one point if they say that haven’t seen the original “Injection”.

2.) How does Cross Site Scripting happen?

Almost every application will eventually print dynamic data into the HTML page. It is important that when your developer writes HTML markup with dynamic data that they do it securely. Otherwise, some lowly intern is going to have the unfortunate job of HTML encoding all of the developer’s markup after your next security audit.  

• Zero points if not capable of defining cross site scripting.
• One point if they use the word "encode".
• Negative one point if they say they are not into religious sites.

3.) What is CSRF?

CSRF stands for cross site request forgery, but it is up to you if you want to tell that to your interview candidate or not. It could make for an awkward moment in the interview process and it very well should. It will prevent having to shoehorn in a CSRF protection solution in after the fact. A very messy proposition. CSRF protection is an important architectural design consideration. If a developer is unaware of it, they will likely forget to implement the protection properly, which will wind up costing you development dollars.

• Zero points if not capable of defining CSRF.
• One point if they use the word “nonce”.
• Negative points if the candidate says they don’t surf.

4.) What is PII?

Applications do a lot of things, but one of the things that they need to do well is to handle sensitive information carefully. Before sensitive data can be handled correctly it helps to know which data is, well, sensitive. Developers do not need to memorize a list of data types that some organization has deemed sensitive. They should, instead, have an awareness of the consequences if the information fell into the wrong hands and be able to make most determinations on their own. Now, if the debate of whether or not a user agent string or zip code by itself should be considered PII comes up, by all means, please reference a reputable source.

• Zero points if not capable of defining PII.
• One point if they can provide examples.
• Two points if they say, “A free year of credit report monitoring”.
• Negative points if they start rattling of all the numbers of Pi they know.

As you can imagine, this list is not exhaustive and easily defeatable on a phone interview, so make sure you mix it up! The important thing to remember is, construction contractors are required to build buildings that meet building codes to prevent collapses and protect its residents. It is time we hold our developers to the same standards.