options (these both take a comma separated list of files; list certificates

and their respective keys in the same order).

After you enablea wildcardsub-domain,[disable path-based apps](../../tutorials/best-practices/security-best-practices.md#disable-path-based-apps).

After you enablethe wildcardaccess URL, you should[disable path-based apps](../../tutorials/best-practices/security-best-practices.md#disable-path-based-apps) for security.

For production deployments, disable path-based apps.

For production deployments,we recommend that youdisable path-based apps after you've configured a wildcard access URL.

Path-based apps share the same origin as the Coder API.

This setup is convenient for demos,but can expose the deployment to cross-site-scripting (XSS) attacks in production.

Path-based apps share the same origin as the Coder API, which can be convenient for trialing Coder,

but can expose the deployment to cross-site-scripting (XSS) attacks in production.

A malicious workspace could reuse Coder cookies to call the API or interact with other workspaces owned by the same user.

1.[Enable sub-domain apps with a wildcard DNS record](../../admin/setup/index.md#wildcard-access-url) (like`*.coder.example.com`)

By default, Coder mitigates the impact of having path-based apps enabled, but we still recommend disabling it to prevent malicious workspaces accessing other workspaces owned by the same user or performing requests against the Coder API.

If you do keep path-based apps enabled, Coder limits the risk:

If you do keep path-based apps enabled:

- Path-based apps cannot be shared with other users unless you start the Coder server with`--dangerous-allow-path-app-sharing`.

- Users with the site`owner` role cannot use their admin privileges to access path-based apps for workspace unless the server is started with`--dangerous-allow-path-app-site-owner-access`.