- 3 minutes to read

HTTP Security Response Headers

In addition to TLS, Nodinite v7 enforces several HTTP security response headers at the application level. Understanding what is set in code — and what you can supplement at the IIS level — is important for security assessments and compliance questionnaires (e.g., VSAQ 2.17).

What Nodinite Sets at Application Level

Header Status Detail
Strict-Transport-Security (HSTS) Enforced Set by app.UseHsts() in all main services: Web Client, Web API, Log API, Monitoring Service, Logging Service
Content-Security-Policy (CSP) Enforced Set in the Web Client with default-src 'self', frame-ancestors 'self', object-src 'none'. Script, style, image and font sources are configurable via Dashboard Plugin Settings
X-Content-Type-Options: nosniff Partial Applied to all bundled JS/CSS static asset responses. Not set globally on all API endpoint responses
Referrer-Policy: same-origin Partial Set in the Web Client controller; not applied globally to Web API or Log API endpoints
X-Frame-Options Covered by CSP Not set as a standalone header; frame-ancestors 'self' in the CSP provides the modern equivalent and is preferred over the legacy header
Permissions-Policy Not set in code Not configured at application level; can be added by the customer at IIS level — see below

Adding the Remaining Headers via IIS

For Permissions-Policy, and to apply X-Content-Type-Options and Referrer-Policy globally across all endpoints, add an HTTP Response Headers rule in IIS. The simplest approach is to add the following to your site's web.config:

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Permissions-Policy"
           value="camera=(), microphone=(), geolocation=(), payment=()" />
      <add name="X-Content-Type-Options" value="nosniff" />
      <add name="Referrer-Policy" value="same-origin" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

Tip

You can also configure these headers through IIS Manager → select your site → HTTP Response Headers → Add — no web.config edit required.

Note

The Content-Security-Policy and Strict-Transport-Security headers are managed by Nodinite application code. Do not duplicate them in web.config as conflicting values can cause browser errors.

Cache-Control and Browser Data Retention

Nodinite does not set a global Cache-Control: no-store header on all responses. Sensitive pages (log payloads, monitor results) are served dynamically and are not cached by the browser beyond the session. However, if your compliance requirements demand explicit cache prevention across all endpoints, add the following to your web.config:

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Cache-Control" value="no-store, no-cache, must-revalidate" />
      <add name="Pragma" value="no-cache" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

Note

Because Nodinite is on-premise software, no data is ever cached on Nodinite-controlled infrastructure. The question of local machine cache applies only to the end user's browser on their own device — which is governed by the customer's endpoint management policies.

Generating Scan Evidence

Because Nodinite is deployed on your own IIS server, you control the endpoint and can generate scan evidence yourself:

  • securityheaders.com – Point at your Nodinite Web Client URL (must be publicly reachable, or use the browser extension for internal URLs)
  • OWASP ZAP – Run a passive scan against your Nodinite instance from within your network
  • PowerShell quick check:
$response = Invoke-WebRequest -Uri "https://your-nodinite-url" -Method Head
$response.Headers | Select-Object -Property @{N='Header';E={$_.Key}}, @{N='Value';E={$_.Value}}

Next Steps

TLS Hardening