NNathan's Technology WikiIT, cybersecurity & learning notes
ArticleReadMain page

Nathan's Technology Wiki / Projects

Cinderstrike Security

A founder-led cybersecurity and practical-AI application built around evidence and secure intake.

Contents
  1. Purpose and audience
  2. Service model
  3. Application architecture
  4. Publishing and intake
  5. Security design
  6. Deployment and validation
  7. Lessons and roadmap

Purpose and audience

Cinderstrike is a founder-led website for cybersecurity assessment, practical AI readiness, secure prototyping, thought leadership, and consultation intake. The product language emphasizes useful decisions, exploit-verified evidence, remediation, and transferring context to the customer.

Version0.1.0
RuntimeNext.js app and private PostgreSQL
Public routeHTTPS through Nginx Proxy Manager

Service and engagement model

The application documents penetration testing, attack-surface assessment, cloud and identity review, incident readiness, security leadership, and AI-readiness or limited secure prototypes. Its four-part method is Observe, Prove, Reduce, and Transfer.

ObserveMap the environment, business intent, constraints, and likely attack paths.
ProveSeparate exploitable risk from scanner noise through authorized validation.
ReducePrioritize changes that remove meaningful risk with practical effort.
TransferLeave clear ownership, context, and repeatable defensive practices.

Application architecture

The stack uses the Next.js App Router, React, TypeScript, GSAP animation, PostgreSQL, JOSE, Zod, and server-rendered Markdown content. Public routes cover the main site, services, AI, about, privacy, blog, and contact experiences. Protected routes provide administration, analytics, and article creation or editing.

Public experienceServer-rendered pages present services, articles, and consultation paths.
API routesHealth, consultation, and analytics endpoints validate and persist approved inputs.
Admin areaA protected control room manages posts, inquiries, status, and analytics.
PostgreSQLStores articles and consultation records without public database exposure.

Publishing and consultation intake

The publishing system supports a blog index, dynamic article slugs, new-post creation, and editing. Consultation submissions record the requester, contact path, requested service, planning range, message, time, and workflow status such as new, contacted, or closed.

Data-handling lesson
Consultation forms collect real contact information, so validation, retention, least-privilege administration, safe logs, and a documented deletion policy are part of the feature.

Security design

  • Administrator sessions are signed and stored in HttpOnly cookies.
  • Production requires independent administrator and session secrets; development fallbacks are disabled.
  • The PostgreSQL service is not published to the host.
  • The application binds to loopback on its host port, and NPM is the public HTTPS entry.
  • Credential material is excluded from source control, Docker build context, and this wiki.
  • Zod validation and server-side actions keep protected decisions out of the browser.

Deployment and validation

Docker Compose runs the database and application. NPM terminates TLS and forwards the domain to the application's dedicated host port. The health endpoint returns success only when PostgreSQL is configured and reachable.

Preflight

  • Lint, build, validate Compose, inspect routes, and confirm secrets are supplied securely.
  • Review database exposure, cookie flags, and NPM hostname/certificate alignment.
  • Draft the Cinderstrike wiki update for planned service, stack, data, administrator, security, and deployment changes.

Postflight

  • Test the public pages, health endpoint, consultation workflow, admin denial, and article publishing.
  • Review logs without displaying submitted contact data or credentials.
  • Update the Cinderstrike wiki with the verified release, operational evidence, limitations, and lessons without publishing client data or secrets.

Lessons and roadmap

  • Marketing, intake, publishing, analytics, and administration are separate responsibilities even in one Next.js application.
  • Business-facing security language should explain outcomes rather than overwhelm users with tool names.
  • AI prototyping starts with network, identity, vendor, logging, recovery, and data-flow assessment.
  • Future releases should formalize migrations, tests, release tags, retention controls, and restoration exercises.
← Main pageProject library →