Safely injecting a JSON configuration object into a Razor Page

While reviewing an ASP.NET Core Razor page application that needed to share server-side configuration with client-side JavaScript, I noticed the following approach to inject a JSON object:

<script>
    var featureFlags= @Html.Raw(Model.FeatureFlagsJson);
</script>

It works — until it doesn't. This post walks through the right way to do it, why the naive approach can blow up in your face, and what the production-safe pattern looks like.

Why the naive approach is dangerous

Directly interpolating server-side values into a <script> block creates an XSS (Cross-Site Scripting) vector. If any value in your config object contains characters like </script>, ", or ', the browser can interpret that as the end of your script tag — or worse, execute attacker-controlled code.

Consider this innocent-looking config value:

public string FeatureFlags{ get; set; } = "My App </script><script>alert('pwned')";

Inlined naively, that produces:

<script>
    var featureFlags= { appName: "My App </script><script>alert('pwned')" };
</script>

The browser sees the </script> as closing your block, and the injected script runs.

A simple and clean solution: <script type="application/json">

I flagged the issue in the PR and asked the developer to find a solution. She came up with a solution I wasn’t aware that it existed: using a <script> tag with a non-executable MIME type as a data container.

@page
@model IndexModel

<script type="application/json" id="featureflags-config">
    @Model.FeatureFlagsJson
</script>

Because the browser only executes <script> tags with a JavaScript MIME type (or no type at all), a type="application/json" block is treated as inert data — the content is never parsed as code. That means a </script> sequence inside your JSON cannot break out of the block or execute anything. The browser simply ignores it as a script.

You then read it in JavaScript with a single JSON.parse:

const configEl = document.getElementById('featureflags-config');
const config = JSON.parse(configEl.textContent);

if (config.featureFlags.newDashboard) {
    initNewDashboard();
}

What on the C# side?

On the C# side, we need to serialize our JSON in a more relaxed (I like the naming) way:

var options = new JsonSerializerOptions
{
    Encoder = JavaScriptEncoder.UnsafeRelaxedJsonEscaping, // safe here — not in a script block
    WriteIndented = false
};

ClientConfigJson = JsonSerializer.Serialize(config, options);

And in the Razor view, standard Razor encoding is fine — no Html.Raw needed:

<script type="application/json" id="featureflags-config">@Model.ClientConfigJson</script>

Razor's default HTML encoding will turn " into " and < into < inside the tag content, which JSON.parse won't understand. To avoid this, we use UnsafeRelaxedJsonEscaping on the C# side (which produces unescaped quotes) and rely on the fact that the browser correctly reads the raw text content via textContent, not innerHTML. The textContent property gives you the decoded text, so " becomes " before JSON.parse sees it.

What about a <meta> tag or a separate endpoint?

Two common alternatives worth knowing about:

<meta> tags work well for a single scalar value but are awkward for a structured object and require manual parsing in JavaScript. Not ideal for a config object.

A dedicated /config JSON endpoint is a clean approach for large or sensitive configs, at the cost of an extra HTTP round-trip before your app can initialize. If your config is large or access-controlled, this is worth considering. For lightweight, non-sensitive config that's available at page render time, the inline approach above is simpler and faster.

Checklist

• Never interpolate raw C# strings directly into <script> blocks
• If using an executable <script> block: serialize with JavaScriptEncoder.Default and use Html.Raw
• If using <script type="application/json">: read via textContent + JSON.parse, not innerHTML
• Keep secrets (API keys, connection strings) off the client config entirely — this is for UI configuration, not credentials If using the application/json approach, make sure your JS runs after the DOM element exists (defer or DOMContentLoaded)

The pattern is simple once you have it in place, and it closes a class of injection bugs that are easy to introduce and nasty to debug.