WordPress: WLWManifest Is A Legacy Feature With Security Implications. Here’s How To Disable It
In the evolving landscape of content management systems, certain features persist long after their original purpose has faded into obscurity. The Windows Live Writer Manifest (WLWManifest) in WordPress is one such artifact, representing a bygone era of desktop blogging tools while potentially introducing unnecessary security risks to modern WordPress installations.
WLWManifest Origins and Purpose
The WLWManifest feature was introduced to WordPress to support Microsoft’s Windows Live Writer (WLW), a desktop blogging application that was part of the Windows Live Essentials suite. This manifest file, typically found at /wp-includes/wlwmanifest.xml, provides the necessary information for Windows Live Writer to interface with WordPress blogs, enabling users to write and publish content directly from their desktops.
Windows Live Writer gained popularity among bloggers in the late 2000s and early 2010s. It offered a rich text editing experience that was superior to many web-based editors of the time. The WLWManifest link in WordPress headers was a discovery mechanism, allowing the desktop application to configure itself for different WordPress installations automatically.
The Decline of Windows Live Writer
Microsoft discontinued Windows Live Writer in 2017, along with the rest of the Windows Live Essentials suite. While the application was open-sourced as Open Live Writer under the .NET Foundation, development has been minimal. The last significant update to Open Live Writer was released in 2017, and the project has seen little activity since then.
Despite this obsolescence, many WordPress installations continue to include the WLWManifest link in their headers, serving no practical purpose for the vast majority of users.
Security Implications
The presence of the WLWManifest link in WordPress headers has attracted attention from security researchers for several reasons:
- Unnecessary Service Exposure: The manifest file serves no purpose on sites that do not use Windows Live Writer or Open Live Writer, making it an unnecessarily exposed endpoint.
- WordPress Installation Detection: Automated scanning tools use the presence of wlwmanifest.xml as one of several indicators to confirm a site is running WordPress. While this information is typically obvious through other means, removing unnecessary identifiers follows security best practices.
- Legacy Code Maintenance: As with any legacy feature, maintaining unnecessary code in a system increases the overall complexity and potential maintenance burden. Modern security practices recommend removing unused components.
<?xml version="1.0" encoding="utf-8" ?>
<manifest xmlns="http://schemas.microsoft.com/wlw/manifest/weblog">
<options>
<clientType>WordPress</clientType>
<supportsKeywords>Yes</supportsKeywords>
<supportsGetTags>Yes</supportsGetTags>
<supportsNewCategories>Yes</supportsNewCategories>
<supportsNewCategoriesInline>Yes</supportsNewCategoriesInline>
<supportsCommentPolicy>Yes</supportsCommentPolicy>
<supportsSlug>Yes</supportsSlug>
<supportsExcerpt>Yes</supportsExcerpt>
<supportsPages>Yes</supportsPages>
<supportsPageParent>Yes</supportsPageParent>
<supportsAuthor>Yes</supportsAuthor>
<supportsCustomDate>Yes</supportsCustomDate>
<supportsFeaturedImage>Yes</supportsFeaturedImage>
<supportsPostAsDraft>Yes</supportsPostAsDraft>
<supportsCustomFields>Yes</supportsCustomFields>
<supportsTrackbacks>Yes</supportsTrackbacks>
</options>
</manifest>While the wlwmanifest.xml file contains only basic feature capability information and doesn’t expose sensitive data like version numbers, its removal is considered a security best practice under the principle of reducing unnecessary exposure. This approach aligns with the general security concept of minimizing attack surfaces by removing unused features and endpoints.
Removing WLWManifest from WordPress
Given these security considerations and the obsolete nature of Windows Live Writer, removing the WLWManifest link from WordPress is a recommended security hardening measure. Add the following code to your child theme’s functions.php file:
add_action('wp_head', function() {
remove_action('wp_head', 'wlwmanifest_link');
}, 1);You may also want to add code to redirect the visitor (or crawler) to a 403 page, declaring the URL forbidden.
add_action('template_redirect', function() {
if (strpos($_SERVER['REQUEST_URI'], 'wlwmanifest.xml') !== false) {
header('Status: 403 Forbidden');
header('HTTP/1.1 403 Forbidden');
exit();
}
}, 1);Verifying Removal
After implementing the code in functions.php, it’s important to verify that the changes have taken effect. Clear both your WordPress cache (if you’re using a caching plugin) and your browser cache, then navigate directly to yourdomain.com/wp-includes/wlwmanifest.xml in your browser.
If you added the additional code, you’ll receive a 403 Forbidden error. If not, a 404 Not Found error. If you still see the manifest file or get a different response, double-check that your functions.php code was added correctly and that all caching layers (including any CDN or server-level caching) have been cleared.
Conclusion
The continued presence of WLWManifest in WordPress installations represents a common challenge in web development: balancing backward compatibility with security best practices. While removing this legacy feature is a relatively simple process, it exemplifies the importance of regularly auditing and updating web applications to remove obsolete components that may pose unnecessary security risks.
For modern WordPress installations, removing the WLWManifest link is a recommended security practice that helps reduce the attack surface of your website without impacting functionality for the vast majority of users. As with any security modification, it should be part of a comprehensive security strategy rather than an isolated change.
Related Martech Zone Content
