Establish Secure-by-Default Service Baseline

[digitalrisedorset]

Summary

Implement the minimum security baseline that every ReactEdge service must provide by default.

This issue creates a reusable foundation that can be applied consistently across Python, Node.js, Go and future services. The objective is to make every new service production-ready from day one while keeping the implementation lightweight and framework agnostic.

---

Motivation

ReactEdge services are designed to be small, interoperable and independently deployable.

Security should therefore be a platform concern rather than something implemented differently by each service.

This first iteration deliberately focuses on fundamental security practices before introducing stronger service authentication mechanisms such as mTLS or service identities.

---

Scope

HTTPS

• Ensure all production deployments are served over HTTPS
• Leverage Caddy automatic certificate management

Configuration

• Store all configuration in environment variables
• Validate required configuration during startup
• Fail fast when configuration is invalid

Secrets

• Never hardcode secrets
• Provide .env.example
• Document required environment variables

Health

• Expose a dedicated /health endpoint
• Avoid leaking internal implementation details

Logging

• Implement structured logging
• Avoid logging sensitive information

Observability

• Instrument the service with OpenTelemetry
• Emit startup, shutdown and request lifecycle spans

Error Handling

• Return consistent error responses
• Avoid exposing stack traces in production
• Log unexpected failures

Documentation

• Add a Security section to the README describing:
  • HTTPS
  • Environment variables
  • Secret management
  • Deployment recommendations

---

Acceptance Criteria

• HTTPS enabled through Caddy
• Automatic TLS certificate renewal documented
• Environment variables validated during startup
• No secrets committed to the repository
• .env.example provided
• /health endpoint available
• Structured logging implemented
• OpenTelemetry integrated
• Consistent production-safe error responses
• README includes a Security section

---

Notes

This issue intentionally excludes:

• API Keys
• IP allowlisting
• OAuth2
• Mutual TLS (mTLS)
• Service identity (SPIFFE/SPIRE)
• Rate limiting

These capabilities will be introduced in subsequent issues as part of the Secure Service Foundation roadmap.