Practical example: building a social sharing platform

Documenting your project upfront requires time and research, but gives enormous amount of insights and knowledge for the whole team to advance with.

In this article we're continuing where we left off my previous article "Documentation of a project" by providing examples for the documentation focus areas I explained and we're also making sure that we're not tumbling down a rabbit hole where specs are written in stone and we're building this project in a waterfall way.

The Hotbrewd project

For this particular example I've chosen a project that has a couple of interesting challenges. It's a social media platform (lots of users) where people can check in their beverage at a specific location or establishment (geolocation), upload photos or videos of their drink (moderation) and share with friends (personal information, profiling). To make it a little entertaining, the more people share and tag, the more stickers they can unlock. Also brands and establishments can offer discounts for specials (marketing, monetisation).

The project feature requirements

Together with the business we define feature requirements. This is a list of requirements made from a business perspective. We need this list to ensure that we can build something the business wants and should contain verifiable criteria. In the case of Hotbrewd, the feature requirements are written out in a specification document. This can be a Word file, a Google document or as we like to use at In2it a wiki entry.

A wiki entry providing feature requirements

Defining technical requirements

Now that we know what the business wants, we can start defining the technical requirements. This sounds easier than it is because at this stage we only have a vague idea what kind of application we're going to build and how the technical infrastructure would look like. But we have no clue how many users will be on this platform, where constraints could be in the network or services or what kind of data is collected that needs protection.

To answer these questions, we are going to interview the developers, system administrators and business owners to note down their views, experiences and expectations. We are focussing closely on how they envision the application. Sketching out their visions helps to find commonalities amongst all stakeholders and to draft up a technical architecture schema.

Quickly after interviewing all stakeholders you can form an idea how the application architecture would look like

Security considerations

Now is a good time to define some security considerations! The business wants to build an application for the masses, but doesn't want to be in the news because sensitive data got stolen or the application got abused. With the help from security experts we can define areas of concern that everyone should be aware of. These areas are:

• Network security
• Systems security
• Application security
• Application abuse

Network security is required to ensure that only the application can access the underlying systems and only has a single entry point (the reverse proxy).

Systems security is oriented towards the operating system (OS) and its libraries or tools that are installed on the platform.

Application security focusses on ensuring that all components of the application are protected agains malicious attacks. Primary area of concern is the OWASP Top 10, a list of 10 most common attack vectors seen in web applications. But just as important are measures taken to ensure the application components can communicate safely and securely.

Application abuse is a risk based analysis of how the application could and would be abused, beyond the scope of the vision of the business. A potential abuse element is the fact people can upload photos and videos. The business would like users to upload shots of their coffees, but nothing prevents them to upload violent or provocative material. Another point of abuse could be stalking, because the application collects information where a beverage is consummated. And when you look at the whole application you come up with a very, scary list of all things that could be abused using the application as designed.

Working towards a POC

With all knowledge gathered, it's a good idea that you work to a first proof of concept (POC). This doesn't require a complete architecture or full infrastructure, but gives everyone a good idea how all things communicate together. And the business has something they can already start playing with the idea and work out how to improve the user experience.

Don't forget to keep meeting notes and add it to the documentation stack!

A first POC, doesn't have to be fancy but should contain the basic requirements

Your project backlog can now be filled with development tasks, security tasks, design tasks, testing tasks and so on. A simple Kanban board can really help out as it makes work visible in the organisation.

A simple Kanban board to make work visible

Now that we have work in the pipeline, an idea on paper and an application to protect, I'm going to take some time to write out all the security related issues I come across and I will put them in writing in my next article. Please keep sending your feedback, suggestions and comments as it helps me get better insights in web application security. See you all next time.