[SEC] restrict CORS to authorized extension IDs

[RaoufGhrissi]

[SEC] restrict CORS to authorized extension IDs
Fixes a security issue where any Firefox extension (moz-extension://.*) could access the ActivityWatch server without any restriction.

Previously, the CORS configuration included a wildcard for all Mozilla extensions by default. This commit removes that blanket permission and introduces granular control through both static configuration and the Web UI.

We've added 2 new fields to the file configuration (allow_aw_chrome_extension and allow_all_mozilla_extension) and 4 new settings to the Web UI (Fixed origins, Regex origins, and extension-specific shortcuts). The server now merges these settings to determine the final set of authorized origins, ensuring a more secure and flexible configuration.

Dependent on: ActivityWatch/aw-webui#795

[greptile-apps]

Greptile Summary

This PR tightens the CORS security posture of aw-server-rust by replacing the previous blanket moz-extension://.* wildcard with two explicit opt-in flags (cors_allow_aw_chrome_extension defaulting to true, cors_allow_all_mozilla_extension defaulting to false). A DB-sync layer is introduced in build_rocket so that Web-UI changes to these settings persist across server restarts.

Key changes:

• config.rs: two new bool fields with correct serde defaults; the previously-reported default_true bug for the Mozilla flag is resolved.
• cors.rs: extension origins are now gated behind the new flags; the testing-mode chrome-extension://.* regex is correctly placed in allowed_regex_origins (prior reported bug fixed); |= assignment issue resolved — simple assignment now used.
• mod.rs: startup DB-sync seeds keys from config on first run and defers to the DB value on subsequent runs. The CORS list fields are serialised as comma-joined strings, which is fragile for any regex pattern that contains a literal comma. Config-file edits after first run are silently ignored with no user-facing warning.
• README.md: documents the two new options and updated defaults.

Confidence Score: 4/5

Safe to merge with minor follow-up work; the most critical previously-reported bugs (wrong default, |= semantics, wrong regex list for testing mode) are all resolved in this revision.

All P0/P1 issues from prior review rounds have been addressed. Remaining findings are P2: the Chrome extension ID is placed in the regex list rather than the exact list (cosmetic), the comma-join serialisation is fragile for regex patterns with commas (edge case, unlikely in practice), and config-file changes after first startup are silently ignored with no log message. None of these block correct operation for the common case.

aw-server/src/endpoints/mod.rs — the DB-sync and comma-join serialisation logic warrants a second look before merging.

Important Files Changed

Filename	Overview
aw-server/src/endpoints/cors.rs	Refactors CORS origin assembly to use the two new config flags; testing-mode regex is now correctly in the regex list. Minor issue: the Chrome extension ID is an exact string pushed to the regex list.
aw-server/src/endpoints/mod.rs	Adds DB-sync logic for CORS settings with correct simple-assignment semantics (prior
aw-server/src/config.rs	Adds two new bool fields with correct defaults (true/false) and matching Default impl; resolves the previously reported default_true bug for cors_allow_all_mozilla_extension.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[build_rocket starts] --> B[Lock datastore Mutex]
    B --> C{DB key exists?}
    C -- No / First run --> D[Seed DB from config file value]
    C -- Yes / Subsequent run --> E[Use DB value, ignore config file]
    D --> F[Update in-memory AWConfig]
    E --> F
    F --> G[cors::cors called with merged AWConfig]
    G --> H{cors_allow_aw_chrome_extension?}
    H -- true --> I[Push chrome-extension ID to regex list]
    H -- false --> J[Skip]
    I --> K{cors_allow_all_mozilla_extension?}
    J --> K
    K -- true --> L[Push moz-extension:.* to regex list]
    K -- false --> M[Skip]
    L --> N{config.testing?}
    M --> N
    N -- true --> O[Push localhost:27180 to exact list
Push chrome-extension:.* to regex list]
    N -- false --> P[Skip]
    O --> Q[AllowedOrigins::some exact + regex]
    P --> Q
    Q --> R[Rocket server starts]

Loading

_{Reviews (4): Last reviewed commit: "[SEC] restrict CORS to authorized extens..." | Re-trigger Greptile}

[greptile-apps]

Fragile JSON string unwrapping via trim_matches

The settings API stores all values JSON-encoded (see settings.rs line 72: serde_json::to_string(&value.0)). So a string like "moz-extension://abc" is persisted in the database as "\"moz-extension://abc\"".

trim_matches('"') strips surrounding double-quote characters, which works for simple ASCII strings, but is not a correct JSON string deserializer. It will silently produce wrong results for values that contain escaped characters. It also won't handle the case where the user stores a JSON array (e.g., ["ext1", "ext2"]) instead of a comma-separated string.

The idiomatic fix is to use serde_json::from_str::<String>(&s):

let parse_cors_list = |key: &str| -> Vec<String> {
    db.get_key_value(key)
        .ok()
        .and_then(|s| serde_json::from_str::<String>(&s).ok())
        .map(|s| {
            s.split(',')
                .map(|s| s.trim().to_string())
                .filter(|s| !s.is_empty())
                .collect()
        })
        .unwrap_or_default()
};

[greptile-apps]

Firefox extension support is effectively broken for all existing users

The original code included the comment:

Every version of a mozilla extension has its own ID to avoid fingerprinting, so we unfortunately have to allow all extensions to have access to aw-server

This is a fundamental Firefox security property: each installation (and each update) of a Firefox extension gets a new random UUID as its origin (moz-extension://<uuid>). This means:

1. There is no single stable ID that a user can add to the allow-list for the ActivityWatch Firefox extension.
2. After every extension update, the old ID is invalidated and the user would need to find their new UUID and update the server settings.
3. Most users have no easy way to discover their current moz-extension:// UUID.

The PR removes moz-extension://.* without providing any workable alternative for Firefox users. Consider either:

• Keeping moz-extension://.* as the default (preserving existing behavior) with clear documentation about the risk, or
• Using a permanent addon ID via browser_specific_settings.gecko.id in manifest.json and documenting that users of unofficial builds need the wildcard.

[ErikBjare]

Don't pass datastore here

[RaoufGhrissi]

i'm hesitating to set default value to True, so it doesn't impact the actual users

[ErikBjare]

...really?

[ErikBjare]

Not a fan of this many additional config keys. Should be prefixed consistently with cors_ such as cors_allow_aw_chrome_extension and cors_allow_all_mozilla_extension.

Curious why the _from_settings is passed along and not resolved/merged into the non-from_settings variants?

[RaoufGhrissi]

merged with the existing vars, and explained in the readme file

[ErikBjare]

I'm a little bit paranoid about letting web UI set CORS like that...

[RaoufGhrissi]

do you have another suggestion to let non-devs configure cors ?