security

🔒

This article is a stub. You can help the IndieWeb wiki by expanding it with relevant information.

security in the context of the indieweb may refer to security concerns regarding personal domains, web hosting, https setup, private data, identity etc. Nearly everything on the internet, including the web, and thus indie web, has security concerns.

Why

Security is not a simple thing that's acquired. It's sometimes referred to as a process. We as site owners ought to take reasonable steps to keep the parts of our sites, DNS, hosting, to build trust with site visitors.

Web pages are often static, but as site owners add capability--for example webmentions or comments--pages are more like software: "web applications." OWASP (Open Worldwide Application Security Project) is a nonprofit foundation that works to improve the security of software and maintains the OWASP Top Ten.

But in general hosting companies often make recommendations about the management of the resources on a website to keep things secure.

How to

See:

CSP
HTTPS
sandbox
Open Worldwide Application Security Project (OWASP) is a non-profit that provides free resources, research, and tools for web application security

Visibility

Services that require logins or act as authorization servers should provide a way for users to see an audit trail of events relating to their account. For example:

GitHub Security History

GitHub provides a page listing accesses to your account with details such as from what device, OS, location, date of access:

Google Recent Activity

Google provides a security recent activity log with date, browser, OS used to access your account and other information:

Breaches

Security breaches as reported by sites

2014

2014-04 Heartbleed
2014-02-15 Kickstarter https://www.kickstarter.com/blog/important-kickstarter-security-notice
...

Vulnerabilities

Vulnerabilities are getting discovered that impact web technologies used by IndieWeb developers and participants in other aspects. Understanding the alerting and process for how vulnerabilities are rated helps when immediate attention is needed to patch and fix our tools.

Common Vulnerabilities and Exposures (CVE)

The CVE is a score for vulnerabilities found. Its number and rating are called, Common Vulnerability Scoring System (CVSS) and the numbering system corresponds to alert terms for ranges. The highest and most serious term is "Critical" and the next highest is "High". A Critical rating most often leads to emergency patching outside of normal update cycles. (More information can be found at the CVE.org site [1]. When the ratings become public, most often the country's cyber security agency or standards organization lists the vulnerabilities in their database and sends out alerts for Critical and High vulnerabilities monitoring groups. In the United States that organization is the National Institute for Science and Technology and its database [2].

Traffic Light Protocol (TLP)

The TLP is the process and restricted sharing naming system related to vulnerabilities and what the process is after a vulnerability is found. When a vulnerability is found it rarely is public, but shared with organizations that can assess the vulnerability and work to find a fix for a patch or change in the system to resolve the vulnerability. Often more than one organization is working on this. The highest level of CVE, Critical, can take a month or few to find a resolution, test it, prepare distribution with partners, and when ready with a fix the CVE is publicly announced. This article from Akamai [3] is a good overview.

Finding Out About Vulnerabilities

Most coding languages and tool maintainers have security newsletters and feeds to follow. When a vulnerability that needs attention these sources are most often really good for finding out early when publicly available.

Incidents

A list of incidents especially relevant to the IndieWeb, and how community members responded.

PHP Vulnerabilities October 2026

On October 21st, 2026, two critical vulnerabilities in PHP were announced that affected significant numbers of PHP installations. See Critical security issue affecting PHP for background.

IndieWeb responses

capjamesg turned off a website he operated that ran PHP until updates were available. He ended up decommissioning the site after learning, completely separate to the PHP events, that the underlying API on which it depended had changed; a rewrite would have been time consuming, so he shut down the site. After this he uninstalled PHP since he wasn't using it.

Reproducible problems

https http botches

Today, when standards like HSTS try to mitigate https to http degradation attacks, there's no reason to allow http at all. All http should redirect to https. Examples of "willful degradation" in indie web related software and services:

Webmentions to Known only work if you mention the http URL. This may encourage using unsafe links to Known (that shouldn't exist in the first place).
webmention.io regards http and https as different URLs. Perhaps this is not a bug, because in a perfect world there wouldn't be any https.

Web Hosting

Should you write about your web hosting setup?

In some regards yes, to help out other members of the community.

However from a security perspective, disclosing what web host you use, software, VPS, or how you implement your server configuration are potential security issues because every piece of information you give a potential attacker about your setup helps narrow the space of weaknesses to explore.

So, how do you share information without endangering yourself in that regard?

You decide you're not a worthy target, or you decide you'd rather share publicly in the hopes that friends will warn you about any flaws before an attacker exploits them.

Dealing with unknown problems

Per https://en.wikipedia.org/wiki/Secure_by_design :

Peer review existing protocols and implementations.
Look for docs, advice, potential peer-reviewers at communities like MIT's Liberationtech mailing list (any other ideas?).
Think in advance about security implications of features like private messages.
Always prefer existing and popular (i.e. constantly peer reviewed) technology to reinventing crypto.
Eventually - prepare guidelines for site owners and developers on the Wiki (similar to Eff's SSD).

Why