{% set baseFontFamily = "Open Sans" %} /* Add the font family you wish to use. You may need to import it above. */

{% set headerFontFamily = "Open Sans" %} /* This affects only headers on the site. Add the font family you wish to use. You may need to import it above. */

{% set textColor = "#565656" %} /* This sets the universal color of dark text on the site */

{% set pageCenter = "1400px" %} /* This sets the width of the website */

{% set headerType = "fixed" %} /* To make this a fixed header, change the value to "fixed" - otherwise, set it to "static" */

{% set lightGreyColor = "#f7f7f7" %} /* This affects all grey background sections */

{% set baseFontWeight = "normal" %} /* More than likely, you will use one of these values (higher = bolder): 300, 400, 700, 900 */

{% set headerFontWeight = "normal" %} /* For Headers; More than likely, you will use one of these values (higher = bolder): 300, 400, 700, 900 */

{% set buttonRadius = '40px' %} /* "0" for square edges, "10px" for rounded edges, "40px" for pill shape; This will change all buttons */

After you have updated your stylesheet, make sure you turn this module off

A 2012 New Year’s Resolution for Developers

by Jason Taylor on January 17, 2012

People often believe that if a developer is capable of creating clean, functional code that they will by default be writing secure code. Unfortunately, this is not always the case.

Security vulnerabilities can result from poor code, functional bugs can be security bugs too, but the trickiest security issues result from code that does more than you expect.. The application may test all of its functional tests but in addition it may have additional unintended functionality that can result in a vulnerability. For instance, a web site with a SQL Injection vulnerability could work perfectly well for a normal user and then work a little too well for a malicious user! It's important to think of abuse cases, not just use cases. Consider what are threats to this application? How would an attacker visualize (and subsequently attack) it? How do I code defensively against these threats?

Although there are many skills and abilities that may be on your personal development wish-list, if you want to write secure code, consider adding the following skills to your repertoire:

  1. Ability to create a mental threat model
    Should include all assets worth protecting and possible threats
  2. Sound knowledge of secure coding standards (known good patterns that work.)
    Ideally this takes the form of both a repository of best practices and a library of secure routines you can call into.
  3. Understand and map input paths and trust boundaries.
    Enables you to make decisions on how much to trust the data your code is processing.
  4. Know (or have a reference of ) patterns of bad code and checklists to check against.
    These are useful to keep in mind while coding as well as to check during a review. In pair programming the second developer can keep these in mind while the first developer is writing code.
  5. Know how your application functions and interacts with its environment.
    You can’t understand how they’d be attacked if you don’t know how they work. Applications ultimately transmit data and operate on hardware, in a network, etc. So you need to understand protocols, dependencies, communications (encryption), etc.

Topics: application security

Most Recent

What's Trending

Featured Resource