Skip to content

Security

It is easier to think of LentyStyle security in three layers:

  • compiler security
  • browser runtime security
  • server and build security provided through guard

The default approach is the fail-closed model. If a security check cannot be completed reliably, the system prefers producing an error rather than silently continuing.

Compile Time

Section titled “Compile Time”

The compiler protects these surfaces:

  • dangerous import URLs
  • declaration and variable payload sanitization
  • prototype-pollution protection for object variables
  • resource limits that cap excessive expansion

This layer tries to stop suspicious or malformed input from silently reaching CSS output at an earlier stage.

Browser Runtime

Section titled “Browser Runtime”

The browser runtime is a convenience layer. Its protection focuses on:

  • initial source URL checks
  • manifest URL checks
  • optional runtime script allowlist and SRI checks
  • worker message payload validation

Core limits:

  • initial .luis sources and manifest URLs must be same-origin by default

Runtime default behavior

Section titled “Runtime default behavior”

In a same-origin setup you generally do not need to write an extra security policy.

<link rel="stylesheet" href="/styles/site.luis" data-luis>
<script src="/runtime/lentystyle.min.js"></script>

In this setup:

  • the initial .luis source is accepted because it is same-origin
  • optional runtime scripts are resolved under the same origin
  • cross-origin initial source and manifest URLs remain blocked by default

Runtime custom policy example

Section titled “Runtime custom policy example”

If cross-origin initial sources or CDN runtime assets are needed, the override must be defined explicitly.

<script>
  window.__LentyStyleSecurityPolicy = {
    allowRuntimeDiagnostics: false,
    allowCrossOriginLuisSources: true,
    allowCrossOriginManifest: true,
    cdnScriptAllowlist: ['https://cdn.example.com'],
    cdnScriptIntegrity: {
      'lentystyle.performance.min.js': 'sha384-REPLACE_WITH_REAL_HASH',
    },
    cdnScriptIntegrityManifest:
      'https://cdn.example.com/runtime/v1.2.3/lentystyle.integrity.json',
    luisSourceIntegrity: {
      'https://cdn.example.com/styles/v1.2.3/site.luis': 'sha384-REPLACE_WITH_REAL_LUIS_HASH',
    },
    styleNonce: 'SERVER_GENERATED_NONCE',
  }
</script>
<link
  rel="stylesheet"
  href="https://cdn.example.com/styles/v1.2.3/site.luis"
  data-luis="performance"
>
<script
  src="https://cdn.example.com/runtime/v1.2.3/lentystyle.min.js"
  data-luis-run="cdn"
  integrity="sha384-REPLACE_WITH_REAL_HASH"
  crossorigin="anonymous"
></script>

This policy is not the minimum CDN setup; it is an advanced override example for a trusted CDN. data-luis-run="cdn" only produces the optional runtime script allowlist and integrity manifest hint. For cross-origin .luis sources, allowCrossOriginLuisSources: true and luisSourceIntegrity are also required separately. debug and map are ignored in production without allowRuntimeDiagnostics: true.

In this example:

  • data-luis-run="cdn" adds the core script origin to the optional runtime script allowlist
  • for the initial .luis source, allowCrossOriginLuisSources: true and luisSourceIntegrity are still required separately
  • cross-origin optional runtime scripts still require matching hashes
  • cross-origin .luis sources are not loaded without a hash/pin; luisSourceIntegrity must match the absolute URL
  • debug and map are ignored in production without allowRuntimeDiagnostics: true
  • styleNonce stamps a CSP nonce on style tags generated by the runtime

Guard Layer

Section titled “Guard Layer”

@lentystyle/guard does not replace the browser runtime. It hardens request, build, or deploy inputs.

Environment-specific entrypoints:

  • @lentystyle/core/guard/runtime
  • @lentystyle/core/guard/hybrid
  • @lentystyle/core/guard/ssr

In practice:

  • the runtime stays as a convenience layer in the browser
  • the hybrid compile entry is protected by @lentystyle/core/guard/hybrid
  • the SSR request entry is protected by @lentystyle/core/guard/ssr

Guard uses a common security vocabulary across these environments:

  • common blocked scheme rules
  • common origin and URL safety decisions
  • common fail-closed finding and policy model

Adapters remain separate, but the underlying security decisions are aligned.

Operations Notes

Section titled “Operations Notes”

Recommended approach in production:

  • serve the runtime from the same origin if possible
  • if using a CDN, add integrity and crossorigin to the core script
  • do not open cross-origin initial .luis sources unless truly needed
  • add the guard layer when build or request-time candidate validation is required