← All work

Open Source · Open Source / Developer Tooling

Starbase

A secure-by-default .NET API template, free under MIT

View on GitHub →

60

test suites

5

architecture decision records

3

database providers

MIT

licensed, free forever

The Problem

Most projects ship with the security work deferred, because the secure version of authentication, MFA, audit logging, and rate limiting is weeks nobody budgeted at the start of a project. Deferred security debt compounds: by the time there is time for it, there is a production database full of records that were written under the old model.

The Approach

  1. 1

    Give away the baseline instead of selling it. A three-person startup that ships with MFA, rate limiting, and proper audit logging costs nothing extra to the world and makes everyone's security posture better.

  2. 2

    Make the secure path the default path, not an option. The template produces a project that already has refresh-token rotation, progressive account lockout, and security headers. There is no 'enable security' step to skip under deadline.

  3. 3

    Document the reasoning, not just the API. Five architecture decision records cover clean architecture, the service response pattern, SQL Server ledger audit, unit of work, and JWT key rotation, so someone adopting it understands what they are inheriting.

  4. 4

    Stay configurable at generation time. Database provider, cloud secrets backend, email provider, and Docker inclusion are template options, so adopting it does not mean adopting a stack.

What It Does

  • JWT authentication with secure refresh-token rotation and key rotation
  • Multi-factor authentication: TOTP, email, WebAuthn/passkeys, and push
  • Per-endpoint rate limiting policies for auth, general API, password reset, and MFA
  • Progressive account lockout with exponential backoff
  • Security headers (CSP, HSTS, X-Frame-Options) and strict environment-specific CORS
  • Hash-chained audit logging with SQL Server ledger tables and partitioning
  • Kubernetes-ready liveness and readiness health probes
  • Serilog structured logging with OpenTelemetry tracing
  • Multi-stage Docker build running as a non-root user
  • Clean Architecture across Domain, Application, Infrastructure, and WebApi layers
  • Choice of SQL Server, PostgreSQL, or Oracle; Azure, AWS, or GCP secret management; six email providers

Engineering Decisions

The choices worth defending in a technical conversation, and why they were made.

Hash-chained audit, on ledger tables

Audit entries chain by hash and sit on SQL Server ledger tables with partitioning. Tamper-evidence has to come from the storage engine as well as the application, because an audit log the application can silently rewrite is not an audit log.

MFA that includes passkeys

TOTP and email codes are the easy half. WebAuthn/passkey support is included because phishing-resistant authentication is the part that actually stops credential attacks, and it is the part most templates skip.

Key rotation designed in, not retrofitted

JWT signing key rotation has its own architecture decision record. Retrofitting rotation into a system that assumed one static key is a migration; having it from the start is a configuration value.

Tested, and testable

Sixty test suites across domain, application, and WebApi integration levels, using xUnit, FluentAssertions, and Moq. A template that ships untested teaches the habit it should be correcting.

The Stack

Core

.NETClean ArchitectureDomain-Driven DesignUnit of Work + RepositoryFluentValidation

Security

JWT + refresh rotationTOTP / Email / WebAuthn MFARate limitingAccount lockoutSecurity headers

Data

EF CoreSQL ServerPostgreSQLOracleLedger audit tables

Operations

Docker (multi-stage, non-root)Kubernetes health checksSerilogOpenTelemetryRedis

Want something like this built?

Let's talk about what you're building and how we can help.