Website engineering team

Key functionality

The website is our main digital presence and allows visitors to learn more about who we are, our products, and purchase them. End users can also manage their licenses, contact our support team via the forum, or read the extensive documentation about Burp Suite.

Our products are however not everything at PortSwigger. If you are interested in web security, you will find invaluable posts from our talented research team, as well as an ever-growing free learning center, the Web Security Academy.

Problem space

Perfectionism and performance at scale are key requirements of the features we deliver. We strive to design solutions that are faster, innovative, and more user friendly. As a result, our team is not afraid of going outside of their comfort zone to identify the right technology to fit the job and push that technology to its limits. Our developers are crafters and engineers of truly scalable products.

As a web security company, a secure website is a must-have. When developing new features, our developers' mindset is highly focused on how new features might potentially be exploited, and we work closely with our in-house security research team.

Technologies

Our website services are running on AWS infrastructure, mainly written in C#, with the addition of JavaScript to enhance the front-end experience.

Our tooling includes Jetbrains Rider, xUnit, git, NuGet, TeamCity, Docker, and various AWS services.

What we've been working on

The website team looks after the public facing side of the website, however that doesn't mean that everything we do is all JavaScript and making pages look pretty. One of the larger components that we look after is our in-house CMS. This system allows the internal content team to write pages for the website, as if they were writing static HTML pages. These pages are all contained in a separate source control repository, with its own release process that is separate from the main website.

Whenever any content is built, we run it through a validator which allows our internal content team to catch early mistakes such as missing closing tags, missing links, or duplicated headings. When it comes to the import process itself, it's a simple drag and drop operation of the bundle of static assets to the site. Those assets are then parsed, reduced to their constituent components, and served through the website as though they were actual dynamic content from the site itself. As far as the end-user is concerned, there is no actual difference in the pages.

The packages are also versioned so that we can roll back as and when required as well as view different versions on different internal environments. This approach gives us the flexibility of releasing these static-content asset bundles without requirement to rebuild the core site, so there is no delay in pushing new content. It also has the benefit of allowing the content authors to work with the tools that they know, rather than expecting them to be experts in development tools or forcing them to use an arbitrary UI.

This is a large and complex system that encompasses the entire stack of .NET web and database development. Where challenges are concerned, the biggest one we routinely face is maintaining our import performance for the large number of pages being updated. Additionally, we have to constantly ensure that any and all pages meet our high bar for security and web standards compliance. A project we recently worked on involved a complete refactoring of the import process - this introduced the versioning system, made sure all code followed best practices, and allows the code to be more easily maintained on an ongoing basis as the number and type of pages grow.