securityLlama

Security Headers Configuration Prompt (LLaMA / Ollama)

Content Security Policy is the most complex security header to configure correctly because it must allowlist every legitimate resource while blocking everything else. This prompt generates a CSP tailored to the specific third-party resources in use, avoiding the over-permissive `unsafe-inline` and `unsafe-eval` directives that negate much of the protection. This variant is formatted for LLaMA / Ollama: Optimised for LLaMA 3, Mistral, and Ollama local models. Uses [INST] / <<SYS>> instruction format.

Prompt Template
[INST] <<SYS>>
You are a helpful, accurate, and detailed AI assistant. Follow the instructions carefully.
<</SYS>>

You are a web security engineer specialising in HTTP security headers.

Generate a complete security headers configuration for the following:

Platform: {{platform}}
Application type: {{app_type}}
Third-party resources used: {{third_parties}}
CSP requirements: {{csp_requirements}}
Environment: {{environment}}

Generate configurations for these headers:
1. **Content-Security-Policy** — tailored to the stated third parties
2. **Strict-Transport-Security** — with appropriate max-age
3. **X-Frame-Options** — or frame-ancestors CSP directive
4. **X-Content-Type-Options** — prevent MIME sniffing
5. **Referrer-Policy** — appropriate for the application
6. **Permissions-Policy** — restrict browser features
7. **Cross-Origin-* headers** (COEP, COOP, CORP) — if applicable

For each header:
- Explain what it protects against
- Note any compatibility considerations
- Provide a testing command to verify it is set

End with the SecurityHeaders.com expected score for this configuration. [/INST]

Variables

{{platform}}Where headers are configured: nginx, Apache, Express.js, Django, Next.js, CloudFront, etc.
{{app_type}}Application type: SPA, server-rendered web app, REST API, static site
{{third_parties}}External resources loaded: "Google Fonts, Stripe.js, Google Analytics", or "None"
{{csp_requirements}}Specific CSP needs, e.g., "allow inline scripts required by legacy code", or "strict mode"
{{environment}}prod (use report-only first to test), dev (relaxed for hot reload), or staging

Example

Input
platform: nginx
app_type: SPA (React, served from CDN)
third_parties: Google Fonts, Stripe.js, Google Analytics (GA4)
csp_requirements: No inline scripts, strict mode
environment: prod
Output
add_header Content-Security-Policy "
  default-src 'self';
  script-src 'self' https://js.stripe.com https://www.googletagmanager.com;
  style-src 'self' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  img-src 'self' data: https://www.google-analytics.com;
  report-uri /csp-report;
" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;

Related Tools

FAQ

How do I test my Content Security Policy without breaking the site?
Use Content-Security-Policy-Report-Only instead of Content-Security-Policy. In report-only mode, violations are reported to the report-uri endpoint but not enforced, letting you fix violations before enabling the policy.
Why does my CSP block inline scripts?
Inline scripts (<script>code here</script> and onclick="...") are blocked by default CSP because they are a primary XSS vector. Migrate inline scripts to external files or use nonces. Never use `unsafe-inline` in production.
What score should I aim for on securityheaders.com?
Aim for A or A+. Missing headers lower the score, but some headers (like COEP/COOP for SharedArrayBuffer) may not be applicable to your app. Focus on CSP, HSTS, and the X- headers as the highest-priority improvements.

Related Prompts