What started as a dream for a worldwide library of sorts, has transformed into not only a global repository of knowledge but also the most popular and widely deployed Application Platform: the World Wide Web.
The poster child for Agile, it was not developed as a whole by a single entity, but rather grew as servers and clients expanded it's capabilities. Standards grew along with them.
While growing a solution works very well for discovering what works and what doesn't, it hardly leads to a consistent and easy to apply programming model. This is especially true for security: where ideally the simplest thing that works is also the most secure, it is far too easy to introduce vulnerabilities like XSS, CSRF or Clickjacking.
Because HTTP is an extensible protocol browsers have pioneered some useful headers to prevent or increase the difficulty of exploiting these vulnerabilities. Knowing what they are and when to apply them can help you increase the security of your system.
In the opening to this series, we discussed what ETags are and demonstrated their most common use case, caching. This time around, we’ll look at a lesser known but perhaps even better feature of ETags: keeping changes safe when writing to the server.
These last few years have seen the rise of some amazing frameworks oriented towards Single Page Application (SPA) like ExtJS, AngularJS, Backbone, Ember, etc. Following the trend where Front-end and Back-end separate. Client side technologies are now being managed by one team and Back-end services by another. This Separation of Concerns is wonderful for implementors as you only need a specification of the API and you can develop functionality concurrently. However all this client-side functionality often leaves the question: How are we going to secure the API if, at least in theory, it should be open for the browser of any device anywhere on earth? (no, we do not support the ISS).
Yet, ETags are one of the features that are the hardest to get right. Sometimes it’s not even clear how they work and while there’s a lot out there on the subject, it can also be difficult to put it all together. Developers frequently play either client and server roles in this exchange, which can make the responsibilities even more confusing.
In this series of blog posts, we’re going to look at ETags from both perspectives: First, a client trying to consume an ETag-enabled API. By focusing on the client side, we can focus on the features ETags offer and learn how these are supposed to look in a perfectly implemented world. In a later post, we’ll look at the gory details of how that API implements ETags and does the appropriate checks.
Likewise if a software project is delivered and no one has looked at security, can it be said to be secure?
If a tree falls... by Dunc(an) When a customer commissions Ibuildings for a new application, he usually has plenty of functional demands (I need it to do X and also Y and Z... oh and can I get A?). And maybe some thoughts have been given to performance metrics, but security? Well... it "needs to be secure".
The web as a mobile platform
The web has been a great place on desktops and laptops for quite some time, but with a booming growth of mobile devices like tablets and smartphones, the internet has become increasingly more interesting on these devices as well. Building mobile apps for the web has some advantages when compared to native development, before we start with Sencha Touch 2 we will take a look at these advantages.
For the morning of tutorial day, I chose to attend Think like an ant, distribute the workload, given by Helgi Þormar Þorbjörnsson. Helgi is a former Ibuildings colleague and now a bigshot at Orchestra.io. I'm happy to see he's doing well. His presentation started off explaining to us why distributing can be a good thing by pointing out three significant aspects: budget, efficiency and perception.