Secure Systems Development with PHP

For many years I have been tasked with creating browser based solutions for teams of all sizes. In some cases a team of just a handful of people. In other cases extended teams at numerous geographical locations.

The web is the perfect solution to such a problem and over time I’ve adopted a number of methods to achieving the desired product.

Back in the day

In the earliest days I’d use Perl or ASP to create web pages with some functionality. JavaScript was in its infancy back then (late 1990s) and not something that could be relied upon for crafting an attractive user experience. It was pretty much all about creating a solution that just ‘did what the client wanted’. These days JavaScript is integral to the entire experience and provides an elegant mechanism for transferring data ‘behind the scenes’.

Modern web systems development

Web development in the modern age is all about the UX (User eXperience) and for that we combine all relevant web technologies; HTML/HTML5, Server Side Script (e.g. PHP), CSS and JavaScript.

When I’m at the early phase of a development I look to pull in resources (some that I’ve written myself and some from reliable 3rd parties) to help kick-start the process.

jQuery and font-awesome, for example, are two indispensable solutions for the modern UI developer. Many solutions exist to wrap all of that for you such that you can just design your system. But I’m somebody who likes to remain very close to the code. The benefits to this are huge and largely revolve around administration and bug fixing which in turn have a direct impact on the cost to the customer – i.e. reducing it!

Securing data transfer

But the point of this post is to explain a little more about how I shift the data around.

I build systems that accept data from the front end (user submitted) and receive data from the back end (server responses).
Every solution is different but in the main I develop solutions to use secure API calls. This is a form of Web Service in that the requesting server need not know anything about the fundamentals or credentials of the responding server. Depending on the application I may adopt a RESTful approach whereby the interface is informed by the responding server in order to satisfy the user’s interaction with the site in a ‘stateless’ manner. Otherwise (and generally) I will adopt a more arbitrary approach whereby the server processes arbitrary commands to satisfy the requesting system independent of the desired workflow.

Form data and all client/server traffic must be encrypted. It’s essential that this is achieved from the outset and of course certificates can be issued from a number of authorities to assist with this. SSL (Secure Sockets Layer) enables the transfer of encrypted traffic and is often evident in your web browser via a padlock and/or a green label in the address bar. It’s not only synonymous with security but also instils trust in your site. Furthermore there is evidence that Google is favouring secured connections in its search algorithms. So using SSL in all scenarios, private or public sites, is advised.

Not all the solutions that I develop are exposed to the web. Some are internal and secured locally but the same procedures apply. Securing traffic is of paramount importance.

Preferred technology

I use PHP. In the past I’ve used ASP.NET with the C# language and achieved some great results. But PHP is so mature now that it’s a pleasure to develop with. There’s a great deal to be said for C# and .NET being developed with Microsoft’s Visual Studio. It is, in many respects, the ideal development environment. But it’s also a real heavyweight of an application. Not always something that developers may be comfortable with.

The PHP community is enormous and there’s a wealth of information out there (some useful, some not) for the everyday developer.

I pass data between domains using PHP’s curl functionality.
In some cases the domains are hosted on the same server which may seem like an unnecessary overhead (calling the PHP code twice), but in most cases the API server and the web host consuming the data are separate.

The important thing is that the mechanics of the API handle Request and Response Objects.

Form input is processed and validated locally and then passed to the API wrapper. This wrapper builds a request that is sent to the API server via curl and JSON encoded response is returned. For successful consumption of the API something as simple as

This framework is essentially boiler-plated such that the nuts and bolts of developing a generic client-specific solution are pretty much my main focus right from the start.

The benefits of experience

The beauty of a couple of decades of experience here is that I can customise and tailor the solution before I consider the front end. That is, I know how I want the data to flow before I provide the mechanisms for updating and requesting it.

My services to customers are governed pretty much by two things; Security and Appearance.

Nobody wants their data exposed to hackers and nobody wants to use something that looks like a dog’s dinner.