Q4 2023 iteration: tracking arbitrary web content, user-specific webhook subdomains, inherited CSP, and more
Hello!
Last week, I kicked off the new "Q4 2023 – Oct-Dec" development and research iteration for Secutils.dev, the open-source toolbox designed for developing and testing secure applications. In this post, I'll take you through the significant features and changes that will be the focus of my work in the coming weeks and months: tracking arbitrary web content, user-specific webhook subdomains, inherited CSP, and more. Let's dive in!
Tracking arbitrary web content
Tracking issue: #secutils/28
In my previous update, I mentioned that Web Page Resources trackers now allow you to specify custom JavaScript scripts to filter and map resources. As I implemented this feature, I had a slightly broader vision in mind: extending this functionality to address use cases beyond web page resource tracking. One such case that has been on my mind for some time is the ability to track changes in any arbitrary web page content or behavior.
Consider this scenario: You're interested in specific content on a web page, such as a list, table, or even navigation bar items, but the page doesn't offer a subscription or notification features. Or maybe you'd rather not create a dedicated account for it. In such cases, the typical approach involves periodically visiting the page and manually scanning for updates — a process that's neither convenient nor efficient. Fortunately, many tasks like this can be automated.
This is where the new functionality in Secutils.dev comes into play. It will allow you to track arbitrary web content as long as you can extract the relevant data using a custom JavaScript script injected to a target web page. While it may not immediately seem related to security, it has its own utility:
- Security researchers can stay informed about new sections or internal links on websites they're analyzing.
- Developers can receive alerts if their production web pages render or expose unexpected content.
- Anyone needing to monitor updates across various unrelated sources, from public repository commits to recent disclosures on random websites, can now consolidate their tracking efforts in a single location.
User-specific webhook subdomains
Tracking issue: #secutils/22
Previously, you could only specify a unique name for the auto-responder webhook. For example, if you named your responder as my-page.html, you'd get the following webhook endpoint URL: https://secutils.dev/api/webhooks/{your_unique_user_handle}/my-page.html. That's perfectly fine for simple use cases where you can directly feed your full webhook URL to a system or service you're interacting with.
However, some services might already assume a certain URL structure and won't allow you to specify the full URL directly. In such cases, you're usually limited to providing only a host name. For example, when testing an interaction between Service A and another well-known Service B, such as Elasticsearch or Supabase, Service A might request only the host name and credentials for Service B, as it's well aware of all Service B's REST APIs. In this scenario, you'd either use dedicated mocking tools (e.g. WireMock) or set up a testing Elasticsearch or Supabase cluster yourself. The latter case can be quite involved, and you'll need to go through various steps to understand exactly what data Service A is sending to Service B.
To address cases like this, Secutils.dev will offer an alternative way to configure and invoke responder webhooks. Each user will be allocated a dedicated webhook subdomain with the ability to configure any path, including the root one (/): https://{your_unique_user_handle}.webhooks.secutils.dev/my-page.html.
It's worth emphasizing that Secutils.dev is not aiming to compete with fantastic mocking tools like WireMock or MockServer, and realistically, it can't. These tools have strong communities and excel at what they do! The goal behind the webhook utility is to complement the Secutils.dev toolbox with yet another commonly used utility in various short-lived security-related scenarios that's incredibly easy and cost-effective to set up and dispose of when no longer needed. A scenario akin to choosing between a universal lightweight Swiss Army knife and highly specialized Wüsthof Chef's knives.
Inherited content security policies (CSP)
Tracking issue: #secutils/16
Currently, Secutils.dev enables you to construct content security policies (CSP) templates through a guided UI. Once you've created a policy template, you can generate a policy ready for use on your website. This approach works well when you have a clear goal and can create a new policy template from scratch.
However, there are times when you'd prefer to base your policy on or "inherit" it from an existing policy. It would be beneficial if, when you create a new policy template in Secutils.dev, you have the option to either specify an existing policy directly or simply point to an arbitrary web page from which to fetch the policy. These changes will enhance the flexibility and usability of Secutils.dev when it comes to managing content security policies.
This is a feature I'll be working on in the upcoming weeks.
Sharing & collaboration
Tracking issue: #secutils/24
As mentioned in my previous post, I’m planning to gradually expand the list of user-generated content that can be publicly shared via Secutils.dev. In this iteration, my goal is to enable the sharing of user certificate templates. This means that anyone with the unique link will not only be able to view the certificate template but also generate a new key/certificate pair. This feature will enhance collaboration and convenience within the Secutils.dev community. Stay tuned for more updates!
That wraps up today's post, thanks for taking the time to read it!
If you found this post helpful or interesting, please consider showing your support by starring secutils-dev/secutils GitHub repository. Also, feel free to follow me on Twitter, Mastodon, LinkedIn, Indie Hackers, or Dev Community.
Thank you for being a part of the community!