DEV Community

Cover image for The Fundamentals of Security Every Developer Should Understand
Ben Halpern
Ben Halpern

Posted on

The Fundamentals of Security Every Developer Should Understand

Last week I made this thread:

I want to share with you some of the great answers. There is a ton of wisdom here, so read on.

  1. Trust no one. Especially yourself.
  2. The only perfectly secure system is one that's been disconnected, powered off, encased in concrete, and dropped into the ocean from a helicopter flown blindfolded.
  3. Any functionality you can use is functionality someone else with ulterior motives can use. Data you can access through your system is data someone else can access through your system. Backdoors are an inherent security risk.
  4. Assume user input is malicious until proven otherwise.
  5. If you're good enough to roll your own crypto, you already have a job working specifically on crypto.
  6. If you only need to test whether input matches something you've stored (like passwords), hash, don't encrypt.
  7. Bind prepared statements, don't interpolate parameters into queries.
  8. If you have a publicly-visible API backing your site, remember that your site isn't the only thing that can hit it.
  9. Think about and test edge cases.
  1. Validate input data!
  2. Seriously, validate input data.
  3. Did I mention validating input data?

The less data you store, the fewer security hazards you expose yourself to, and the safer your participants will be. Don't hoard data on the theory that it'll become useful - only save what you need, and question yourself every time you get into a situation where you think you need it.

If you must store data, especially sensitive data, don't ever store it in plain-text! Look into hashing algorithms like bcrypt.

Always give your participants the option to delete their data, and actually delete it when they ask you to.

  • Security is hard. It's worthwhile to read about various attacks to understand the magnitude of ways in which stuff is attacked.
  • Your system will be breached. Mitigation strategy is as important as the "wall".
  • A system is never "secure", you can only balance security goals with current risks and available resources.
  • Privacy is inseparable from security. Even if you're irresponsible and don't care about your users, the attackers will.
  • Security becomes harder as the data becomes more valuable. Most systems are really only secure because nobody really wants the data they store. As a company becomes successful, the attackers will come.
  • Security is a moving target. You are are never done implementing security.
  • User security is as important as corporate security.
  • Being open about security is the only way to know it's correct. There is no security through obscurity.
  • Everybody is responsible for security. Every person and every machine is a potential attack vector.

Practical advice:

  • Use existing libraries
  • Follow best practices
  • Keep everything up-to-date
  • Be open and ask questions
  • Code defensively
  • Be aware of risks

Whenever you process data from the outside, always process it in this order:

  1. Sanitize
  2. Validate
  3. Execute
  4. Display feedback

Example:


$errors = array();

// 1. Sanitisation
$email = filter_var($_POST['email'], FILTER_SANITIZE_EMAIL);

// 2. Validation
if (false === filter_var($email, FILTER_VALIDATE_EMAIL)) {
   $errors['email'] =  "Invalid email address";
}

// 3. Exécution
if (count($errors)> 0){
    echo 'There are errors : ';
    print_r($errors);
    exit;
}
// At this point, all is fine, let's open the gate...
$bdd = new PDO('mysql:host=localhost;dbname=test', 'root', '');
//...

// 4. Feedback information
Enter fullscreen mode Exit fullscreen mode

Speaking of fundamentals...

I hope this was helpful. There are a lot of specific rules we can follow in terms of security, but starting from principle is key. And we can never assume that everyone already knows and grasps the fundamentals. Go forth and secure your software!

Top comments (9)

Collapse
 
ben profile image
Ben Halpern • Edited

Of course, thanks to all the dev.to folks that chime in on these kinds of threads. This kind of willing wisdom sharing is such a big part of what makes the dev.to community special. 😇

Collapse
 
jodydott profile image
Jody Dott

Regarding prepared statements. Look into what your driver does with them.
Some drivers just concatenate the strings (no protection at all), others do a sanitised concatenation, the best send it to the server to compile and then send the parameters to the server in separate calls (best).

Know what your driver does! Don't assume.

(Also don't rely on this mechanism.. CHECK YOUR INPUTS!)

Collapse
 
embedthis profile image
Michael O'Brien • Edited

These are great. Here is my 2-cents to add to your list:

This has some good overlap with your items and a few others to add:

Web Developer Security Checklist: dev.to/powerdowncloud/web-develope...

Collapse
 
nnthuan profile image
T.s

Would be a good to point out essential maturity of security development.

  • Level 1 would be developing security awareness.
  • Level 2 would be developing security by default.
  • Level 3 would be developing security by design.
  • Level 4 would be developing defensive security in code.
Collapse
 
patrickodacre profile image
Patrick O'Dacre

Thanks for posting this. I learned a lot, and the Darkwing Duck image just about triples the credibility of the advice here.

Collapse
 
bzdata profile image
Beatriz

What are your thoughts about access-controlled documentation and restricting libraries with known vulnerabilities (CVEs)?

Collapse
 
realdolos profile image
Dolores Greatamsky
4. Assume user input is malicious until proven otherwise.

Corollary: You cannot prove a negative as in "not malicious".

Collapse
 
5456qwe profile image
1214586

thanks

Collapse
 
kresnasatya profile image
Kresna Satya

The secure apps or Web is no code. Seriously: github.com/kelseyhightower/nocode