[Design Discussion] Application Security Hardening & Compliance

[brionmario]

Related Feature Issue

#1979

Problem Summary

As Thunder evolves, ensuring strong application security across all layers (frontend, SDKs, APIs, and infrastructure) is critical—especially for enterprise customers with strict security requirements.

Currently, security considerations such as CSP compliance, secure headers, dependency vulnerabilities, and runtime risks are handled in a fragmented manner. This creates inconsistencies and potential gaps in protection.

High-Level Approach

• Establish a centralized security baseline for all applications and SDKs

• Standardize implementation of:

  • Content Security Policy (CSP)
  • Secure HTTP headers
  • Authentication and session handling best practices

• Introduce SDK-level security controls (e.g., CSP nonce support, safe defaults)

• Track and remediate dependency vulnerabilities continuously

• Define secure integration patterns for third-party services

• Enable security observability (logging, reporting, alerts)

Architecture Overview

Components:

• Frontend Applications (React / JSP / etc.)

  • Enforce CSP and security headers
  • Integrate SDKs with secure configurations

• SDK Layer

  • Provide secure-by-default behavior
  • Support CSP compliance (e.g., nonce for injected styles/scripts)
  • Avoid unsafe patterns (e.g., inline scripts/styles without protection)

• Backend / API Layer

  • Enforce authentication, authorization, and input validation
  • Implement rate limiting and abuse protection

• Security Tooling & Monitoring

  • Dependency scanning (e.g., npm audit, Snyk)
  • CSP violation reporting
  • Logging and audit trails

Security Considerations

1. Content Security Policy (CSP)

• Avoid unsafe-inline and unsafe-eval
• Support nonce/hash-based policies for dynamic content
• Restrict external resources via allowlists

2. Secure HTTP Headers

• Strict-Transport-Security
• X-Content-Type-Options
• X-Frame-Options / frame-ancestors
• Referrer-Policy
• Permissions-Policy

3. Dependency Security

• Regular vulnerability scans
• Automated upgrades where possible
• Eliminate high-risk dependencies

4. Runtime Risks

• XSS (Cross-Site Scripting)
• CSRF (Cross-Site Request Forgery)
• Clickjacking
• Injection attacks

5. Data Protection

• Secure storage of sensitive data
• Encryption in transit (TLS)
• Proper session/token handling

Impacted Areas

• Frontend applications
• SDKs (Auth SDKs, shared libraries)
• API layer and services
• DevOps / deployment pipelines
• Developer experience (DX)

Alternatives Considered

Alternative 1: Handle security per team/application

• Pros: Flexible, minimal coordination
• Cons: Inconsistent security posture, higher risk
• Decision: Rejected in favor of centralized baseline

Alternative 2: Enforce strict policies without SDK support

• Pros: Strong enforcement
• Cons: Breaks integrations, poor developer experience
• Decision: Combine enforcement with SDK-level support

Alternative 3: Focus only on backend security

• Pros: Simpler scope
• Cons: Leaves frontend vulnerable (e.g., XSS, CSP issues)
• Decision: Full-stack security approach required

Questions for Community Input

1. What should be the minimum security baseline for all applications?
2. Should security features (e.g., CSP, headers) be enforced by default or configurable?
3. How do we balance strict security vs developer experience?
4. Should we provide built-in tooling/templates for secure app setup?
5. How do we handle third-party integrations that don’t meet our security standards?
6. What level of observability (logs, reports) should be mandatory?