skip to main content
Menu

Is WordPress to blame for the budget leak?

Recently in the news there has been a lot of talk about the OBR’s usage of WordPress over the leaking of the UK Government’s budget, but is it really WordPress the component that is at fault to the budget leak, or is there more to discuss?

Despaired LEGO businessman sitting at a desk

Partially yes, and partially no. Reading from the write-up from the BBC on the technical parts which happened during the incident it sounded as though it could have potentially arisen from misguided technical requirements.

1. Keeping non-public files away from public servers

The biggest blow which caused this was the actual end-goal file URL was guessable. WordPress by default has all files in the media library, and by default, all of these files are assumed to be public. Publicly available via the REST API, publicly available by their URL.

For something as important as the budget, where it absolutely should not have been uploaded before it was due to be announced, then it really shouldn’t have even touched a public facing service no matter the software installed on it. This removes the finger from WordPress essentially, as ANY software which assumed a document uploaded to it was for public viewing and published it under the filename given, could have been guessed.

2. Why just have the PDF available?

If anything doing an “Apple” and taking down the entire store page while the new content was uploaded as presumably other pages would have needed updating to talk about the contents of the PDF, considering the UK Government’s own guidance advises against just publishing PDFs and to focus on webpages as well.

This works well with WordPress as many web hosting platforms that support WordPress (cPanel, Plesk, 20i etc) all allow for a “staging site” which could have been set up for internal usage only and checked by all stakeholders involved, and then replaced/merged wth the live website just after the budget is announced properly.

Even if this is not available, the entire web server firewall could have been changed quite easily to remove access from everyone but stakeholders, verified via VPN, new content uploaded, and then when ready remove the block and allow the public to view again.

3. Be cautious with plugins

Some of the finger is pointed at Download Monitor – a plugin available for WordPress to track downloads of files uploaded to it. This really feels slightly out of place as the plugin description doesn’t even mention privacy over uploaded files in the first place, and just simply tracking of downloads via specific methods.

For private files that should not be directly available to the internet, we recommend checking the plugins work as they say they do by testing them. Check the link for a dummy file, and see if you can access it and get around it by basic means.

Or, usually for sensitive documents don’t have them uploaded to a web server. Depending upon the situation, we recommend using either membership portals which can generate single-use links for documents for logged in users or other routes where a user is logged in and allowed access, or to use software like Zoho WorkDrive and have all members of staff/external users added to a folder to securely share access to documents and information.

Otherwise, if it’s just a URL assume it is public.

Conclusion

In conclusion we still recommend using WordPress as this wasn’t the component which caused a problem here, and seemed to be more of a human error in assuming the functionality of the website, and also the process of publishing a new budget online.

While likely the UK government won’t be reading this blog post, we can definitely help out your business when it comes to allowing access to sensitive resources, or ensuring content is as private as it can be, contact us to see how we can help!