Designing for security

In designing any system and especially systems with a public facing interface, security is always a concern.

Jerome and Michael in an awesome paper titled The Protection of Information in Computer Systems layout general security principles that I think would be of great help to any designer, so below is a summary of the principles.

Least Privilege

An entity in the system should have the minimum set of permissions needed to carry out the actions for which they are authorized.

This may seem intuitively obvious but a lot of applications have the ability to read or even modify privileged information. This exposes the system to a possibility of wide damage in case they are ever hacked.

Fail safe default

A users access to any particular area in the system should by default be denied unless a specific permit is given.

Guess now you know why you had to signup to use an API.

Economy of Mechanism

This again boils down to a principle we talk about frequently on this blog KISS (Keep It Simple Stupid).

All component interfaces and interactions between them should be simple enough to understand.

Complete Mediation

A system should always validate access rights when a request for a resource is made.

That is never try to cache permissions based on any parameter. However, make it easy to generate new authorization taken when need be.

Separation of Privilege

This principle states that granting of privileges should not be based on a single condition.

While this may seem counter intuitive at first think about say a bank manager who grants access to the vault. If the manager has this absolute right and he’s the only one that does, then what happens when the manager first needs access to the vault?

Least Common Mechanism

Systems working in concert should share the least amount of information needed.

This helps prevent spread of invasion from one machine to the next.

Psychological Acceptability

At the end of the day your system is useless if you protect it so much that no one is interested in using it anymore.

That is whatever security mechanisms you put in place, they should not make the resource harder to access than if the mechanisms we’re not there.

Have you used any of the above principles in the design of your own system? Talk to us.


Interface design: What to consider

As a back-end developer, the code you write is meant to be primarily consumed by other developers in writing their services. To this end, you would want to know how well written the interface is. This information will give you a sense of the adoption levels for your service.

Today we will take a quick dive into some of the measures that you can use to evaluate your interface design.


A concise interface enables maximum action with the smallest number of commands. To illustrate this point imagine inputting data to your program. You have the option of either

  1. Keyboard
  2. Screen Display of characters

In this example, typing in the keyboard is clearly more concise. You can get input data far more quicker.

Another way to think of the problem is by comparing programming languages


public class HelloWorld
    public static void main (String[] args)


echo "Hello world";

Clearly PHP is more concise.


Expressiveness describes the interface’s ability to command a wide variety of actions in its domain. This effect can be more readily seen in specialist fields. For example if you are writing code or library for AI, a specialist language like prolog maybe more suited to the task than a more general purpose language.


| ?- likes(mary,food). 


function likes($item,$subject,$person,$database){
       return array_search($item,$database[$person][$subject])!==false; 
echo likes('food','likes','mary',$people);

And prolog shines for even more complex conditionals.

Ease of use

This relates to how many things a developer must know in order to use your code.

If your application has a GUI interface then this is rather low since the knowledge required can simply be summed up to point and click. However TUI applications ease of use drops significantly.

This is not to say that TUIs are bad, in a different context, say if your application is being used as a service library then a TUI interface is great for ease of use.


This boils down to your application. It should not only be doing the right thing, but must also be seen to be doing the right thing.

You can greatly improve on transparency by providing useful feedback to the user, providing solid error management, well written error messages, intermediate results etc.

It would also help a lot if you ship your code source as well.


Your application can be considered discover-able if it assists the user to master it. Comments, context sensitive assistance, Doc Blocks etc ensure that it is easy for the developer to find out what they don’t know about your application.

If a convention, best practice or standard exists for expressing or solving the particular problem, use it.

What do you normally consider when developing the interface for your service? Talk to us on the comment section below.