Case Study – Building a Website for Resilience

Aug 29, 2019 | Software Development | , , , , , | 0 comments


 Recently EverythingsA.com took on a project for an organization that was looking for a developer willing to donate time and resources to build a website to petition against Netflix, Disney and Hulu for threatening to stop producing shows in Atlanta because of the signing of the abortion heartbeat bill earlier this year by the governor of Georgia.  This website ended up becoming redpetition.com which received some media coverage and was very controversial.  This article is a case study of the way we approached the solution for this website.

The Constraints & Requirements

Every project has constraints and requirements.  In this case the requirements were pretty open ended, they just wanted a solution that encouraged the visitor to cancel their Netflix or Hulu subscription and also indicate if they have changed their mind on signing up for Disney Plus due to be released later this year.  The wanted the solution to provide the ability for a visitor to sign a petition if they did cancel or change their mind and record which subscription plan they had canceled.  They then wanted the solution to report a calculated total estimating the loss of annual revenue due to the liberal political stand these companies were taking.  They also wanted to solution to make it easy for visitors to share a link to the petition website on social media.

This is not hard to build with modern web development technologies but the constraints had an interesting effect on the final version of the solution that we went with.  The constraints were as follows:  First, the solution had to be built literally as soon as possible to take advantage of the attention this was getting in the media.  We put five days work in from start to finish going from concept to a live solution.  Second, the nature of the subject matter made it likely that people would not want the website to stay online, so we made it a priority to ensure our solution was resilient against the possibility of attack via DOS and DDOS attacks. 

Our Solution Approach

When building a website or any technical solution, there is always more than one way to solve the problem with technology.  Further, there isn’t necessarily always one right solution.  Besides the functional requirements of a petition and reporting the annual loss real time the major constraint that shaped the design of the solution was the need for resilience against attacks that would attempt to bring the site down.  This meant that a standard simple solution for a website would not be appropriate for this project.  The problems we had to solve were as follows.  First, a standard website form would not work because it could be a point of vulnerability for an attack that would flood the web server with HTTP requests and impede the use of the solution.  Given that we were also hosting the solution we didn’t want to add that strain to the infrastructure.  Second, for the same reason a largely dynamic solution would also be an issue. 

How did we solve these problems?  First, we took the decision to not implement a form on our website but instead to use Google Forms to handle the collection of the petition.  We did this to shift the burden of an attack on the form from our infrastructure to Google’s infrastructure pitting Netflix against Google’s infrastructure rather than ours.  We stored the results in a simple Google Sheet that could be programatically accessed by a few lines of JavaScript to display the real time annual profit loss for the three companies.  Second, we took advantage of Google’s Re-Captcha functionality to limit the possibility of Bot’s ruining the integrity of the data.  We also implemented form validation against the form using the Google Apps Script API to ensure that duplicate petition’s were not submitted among other things.  Third, everything else on the website that we hosted was simple static HTML to limit the resource burden on the web server.  Taking this very simple approach also meant that we could deliver in the very short timescales required by the client.

This post only covers the software aspect of the solution, we also implemented a number of best practices on the hosting side of the solution to mitigate the risk of DOS and DDOS attacks.

The Results

Our suspicions were right.  Within 12 hours of going live we encountered our first DDOS attack, while it wasn’t that big it was big enough at 16gbps and it wouldn’t be the last either.  EverythingsA.com didn’t have control of the DNS and the attacks were bypassing CloudFlare and targeting the IP directly.  We kept the site live by moving it over to another IP Address.  Two days later, there was another DDOS attack, this time it was 38gbps which is a completely different beast.  The same approach was used bypassing CloudFlare and attacking the IP address directly.  If we had built the solution on a standard CMS in something like WordPress using a MySQL database it is likely that the website would have gone down for at least some time as a result of this attack.  Fortunately we were able to keep the solution live throughout all of this, large in part due to the solution design that we implemented using Google forms and a largely static HTML implementation.


While challenging due mainly to the very tight delivery timescales, this project was interesting because of the nature of the content being so controversial and it was great to see our solution stand up against the DDOS attacks that we had anticipated.  There are probably other ways to implement a solution to cater for this, but this one worked and in the end that is what matters the most when building a solution of this kind.


Submit a Comment

Your email address will not be published. Required fields are marked *