sw-loader.php missing direct access protection and using raw PHP file operations

[CoachBirgit]

Description

Two issues in the Service Worker loader file:

1. No direct access protection. The file can be loaded directly by navigating to its URL. Add an ABSPATH check at the top of the file.

2. Using readfile() instead of WP_Filesystem. WordPress.org requires file operations to go through the WP_Filesystem API rather than raw PHP functions.

Action needed

Add at the top of the file:

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

Replace readfile() on line 21 with the equivalent WP_Filesystem method.

Note: This file serves the Service Worker JS, so it may intentionally need direct access (Service Workers are fetched directly by the browser). If that's the case, document why the ABSPATH check is skipped and consider using wp_die() with a nonce check instead, or suppress the PHPCS rule with an inline comment explaining the rationale.

PHPCS rules

• missing_direct_file_access_protection (ERROR)
• WordPress.WP.AlternativeFunctions.file_system_operations_readfile (ERROR)

[ivdimova]

Both items from this issue were already resolved in PR #201 (commit e752d16).

Verified in current sw-loader.php:

• ✅ ABSPATH check: Intentionally omitted with documented rationale — this file is loaded directly by the browser as a Service Worker registration request; WordPress is never bootstrapped, so ABSPATH is never defined. The header comment (lines 9–14) explains this clearly.
• ✅ readfile() vs WP_Filesystem: phpcs:ignore WordPress.WP.AlternativeFunctions.file_system_operations_readfile with justification — WP_Filesystem is unavailable since WordPress isn't loaded, the path is hard-coded via __DIR__ with no traversal vector, and readfile() is the correct single-syscall approach for streaming a static asset to stdout.

Closing as already resolved.