REST -What It’s Good For (Part 1: HTTP Caching)

So I already covered some of the misconceptions around REST in my previous post (if you haven’t read it, please do), but I want to delve into some of the advantages of using such a methodology. This pattern assumes a simple point-to-point, client/server, request/response architecture, which is far from the only way to skin a cat out in IT land, but if it fits your app, REST can give you certain benefits. Today I will focus on HTTP Caching.

Continue reading

Advertisements

Agile Testing & BDD eXchange 2016 (Part 2)

A few months ago I had the opportunity to go to the Agile Testing & BDD eXchange 2016 conference (https://skillsmatter.com/conferences/7428-agile-testing-and-bdd-exchange-2016). I’ve finally had the chance to write up the notes I took (if any of the speakers are reading this and feel that I’m ‘stealing their lunch’ or infringing on their rights, please let me know and I’ll remove the offending content.)

The notes below reflect my own jottings down and interpretations, and not necessarily the views of the speakers. 

Continue reading

Agile Testing & BDD eXchange 2016 (Part 1)

A few months ago I had the opportunity to go to the Agile Testing & BDD eXchange 2016 conference (https://skillsmatter.com/conferences/7428-agile-testing-and-bdd-exchange-2016). I’ve finally had the chance to write up the notes I took (if any of the speakers are reading this and feel that I’m ‘stealing their lunch’ or infringing on their rights, please let me know and I’ll remove the offending content.)

The notes below reflect my own jottings down and interpretations, and not necessarily the views of the speakers.

Continue reading

REST: What It Is (and What It Isn’t!)

REST (Representational State Transfer) has been bandied around as a term for a long time when it comes to API design, and it’s not hard to see the attraction. It relies on the pre-existing HTTP protocol, which is pretty much what the web already runs on, and if implemented well it can make use of a lot of features of HTTP (such as caching).  This is a huge boon to application developers, saving them having to learn/implement a new technology/protocol and implement these features themselves. Continue reading

Six Pillars Of Security, #6: Appropriate Escalation and Containment

  • In the event of a breach or an infringement of your companies responsibilities, timely and appropriate escalation is required.
  • During one breach I witnessed at a company I used to work for, inappropriate and untimely escalation made the situation a lot worse; the dev team and their managers failed to escalate a serious issue (users credentials being logged in a log file) quickly and appropriately, and as result the situation escalated.
    • access to files is often logged. In the case of a breach, the lower the number of people who accessed the compromised resources the smaller the aftermath (e.g in the case of sensitive data being logged to a file, it’s easier to deal with five people who accessed the compromised file, than thirty). Reducing initial propagation helps this.

Continue reading

Six Pillars Of Security, #5: Controlling External Risk

Once data leaves your system, your ability to control it rapidly diminishes. However there are steps you can take to mitigate risks:

  • Only giving clients the data they require
    • For example, with a centralized service application this would involve analyzing what each client needs, and applying logic so that they only receive that information.
  • Actively engaging with client teams, asking them about security, guiding them. Even though the data has left your system, it is still your data and you need to ensure others are being careful with it.

Continue reading

Six Pillars Of Security, #4: Not Helping The Bad Guys

  • Systems often accidentally reveal their workings and vulnerabilities:
  • Revealing the server/component type and version in their error response -this allows the attacker to search for known vulnerabilities against that version number.
  • Logging full stack traces, or worse showing them in the error response -again, this tells the attacker what libraries the system uses, and if any of those libraries have known vulnerabilities, the attacker can exploit this.
  • Just because your client is internal and not ‘user facing’ don’t assume that your error responses won’t filter through to the outside -in a highly distributed system, you never know where your response will end up.
  • Same goes for logging; you don’t know who will end up reading your error logs.
  • Basic Action Points For A Team:
    • Never log full stack traces, unless absolutely necessary.
    • Confirm that non of your responses contain information about the server products you use or their versions.