Security Architecture · Trust · Transparency

Security Architecture & Trust

A transparent view of the controls, architecture, and design decisions protecting AhmedRabeeah.com and its supporting services. The focus is simple: use verifiable controls, minimize unnecessary exposure, keep secrets server-side, and make trust visible without turning security into theater.

Explore architecture → Vulnerability Watch

HTTPS + HSTSTransport enforcement

DNSSECDNS integrity

CSP + CORSBrowser trust boundaries

Live architecture map

Client Visitor Browser HTTPS · CSP enforced

Edge Cloudflare DNS · DNSSEC · TLS · Worker routing

Primary Site ahmedrabeeah.com Static portfolio · Apache headers

Security API vuln.ahmedrabeeah.com Cloudflare Worker · CORS restricted

Persistence Cloudflare KV Latest successful intelligence snapshot

Sources NVD · CISA · FIRST CVSS · KEV · EPSS enrichment

Architecture Overview

The site separates the public portfolio from vulnerability-intelligence processing. Browser-side code receives only normalized public data. Secrets and upstream API access remain inside the Worker boundary.

Implemented

Static Portfolio Surface

The public portfolio is delivered as a static site with Apache-level security headers and no client-side secrets.

Surface: ahmedrabeeah.com

Implemented

Dedicated Intelligence API

Vulnerability intelligence is isolated on a dedicated hostname rather than mixed into the primary site origin.

Surface: vuln.ahmedrabeeah.com

Implemented

Server-Side Secret Handling

The NVD API key is stored as a Cloudflare Worker secret and is never exposed to browser JavaScript or static HTML.

Boundary: Worker secret

Implemented

Persistent Edge Snapshot

Cloudflare KV stores the latest successful normalized dataset so visitors do not trigger upstream security feeds directly.

Storage: Cloudflare KV

Implemented

Scheduled Refresh

The Worker refreshes vulnerability intelligence on a scheduled cadence while preserving prior data if an upstream refresh fails.

Design: fail-soft availability

Implemented

Browser Trust Boundary

CSP limits outbound browser connections and CORS restricts which site origins may consume the vulnerability API.

Controls: CSP + CORS

Implemented Controls

These controls reflect the current site architecture and configuration. The goal is to document what is actually implemented rather than display unsupported security claims.

Control

Status

Purpose

HTTPS

Active

Encrypts browser traffic and protects data in transit.

HTTP Strict Transport Security

Active

Instructs supported browsers to use HTTPS for the domain and configured subdomains.

DNSSEC

Enabled

Adds cryptographic integrity to DNS resolution.

Content Security Policy

Active

Restricts scripts, styles, fonts, images, frames, workers, and outbound connections.

Frame Protection

Active

Prevents the portfolio from being embedded in hostile frames.

MIME Sniffing Protection

Active

Reduces content-type confusion through X-Content-Type-Options.

Referrer Policy

Active

Limits unnecessary referrer information crossing origins.

CORS Restriction

Active

Allows browser access to the vulnerability API from approved portfolio origins.

Worker Secret Storage

Active

Keeps the NVD API credential outside HTML, JavaScript, and public source files.

Cloudflare KV Persistence

Active

Separates public reads from upstream intelligence collection and preserves the last successful dataset.

Security Design Decisions

Separation of Concerns

Public site and intelligence service are separated.

The portfolio remains a simple static attack surface while the Worker handles external APIs, normalization, caching, and scheduled refreshes.

Credential Exposure

No NVD API key in browser code.

All authenticated NVD calls originate from the Cloudflare Worker. The public interface receives only sanitized JSON intended for display.

Resilience

Last-known-good data is preferred over failure.

If an upstream source fails during a scheduled refresh, the previous successful KV snapshot remains available to visitors.

Trust Boundaries

Browser connections are explicitly allow-listed.

The site CSP permits only intended network destinations, while the vulnerability Worker restricts cross-origin browser access to the portfolio origins.

Security Transparency

Document what exists, not what sounds impressive.

This page intentionally avoids claims about controls that have not been configured or independently verified.

Risk Prioritization

Severity is only one input.

Vulnerability Watch combines CVSS, CISA KEV, EPSS, exploit references, ransomware context, network reachability, and attacker prerequisites.

Trust & Verification

Live service verification

The vulnerability service health below is retrieved directly from the public Worker health endpoint.

API statusChecking…

Storage—

Dataset initialized—

Last successful refresh—

Source health—

Verification scope

This page separates documented controls from dynamic service checks.

Dynamic checks are used where the browser can verify a public service directly.

Configuration controls are documented based on the deployed site architecture.

No claim is made that this site has been independently audited or certified.

No sensitive credentials, private keys, or internal configuration details are published here.

Responsible security contact

Security-related concerns can be reported using the site contact address.

[email protected]