How I Built a Secure Portfolio From the Ground Up

Why Security Starts at Architecture

When most people think about securing a website, they think about firewalls, penetration tests, and vulnerability scanners. But the most powerful security decision you can make happens before you write a single line of code: choosing the right architecture.

For my personal portfolio, I made a deliberate choice to build a static frontend — a site with no database, no server-side code, and no user authentication. This wasn't a limitation. It was a security strategy.

The Threat Model: What Am I Actually Protecting?

Before building anything, a security-conscious developer should ask: what are the realistic threats, and what am I protecting?

For a personal portfolio, the threat model is straightforward:

Asset	Threat	Likelihood
Visitor data	Data breach	Low — no data collected
Site availability	DDoS attack	Medium — mitigated by CDN
Site integrity	Defacement / XSS	Low — no user input stored
My reputation	Impersonation	Low — HTTPS + domain lock
My email	Spam / phishing	Medium — public contact info

Understanding this threat model shaped every technical decision that followed.

Decision 1: Static-First Architecture

A static site has no backend server processing requests, no database executing queries, and no session tokens to steal. This eliminates entire categories of attack:

• SQL Injection — impossible with no database
• Remote Code Execution — impossible with no server-side runtime
• Authentication bypass — impossible with no login system
• Server-side request forgery (SSRF) — impossible with no server

This is the principle of minimising the attack surface — one of the foundational concepts in security engineering. Every component you add to a system is a potential vulnerability. The fewer components, the smaller the surface.

Decision 2: HTTPS Everywhere

All traffic to my portfolio is encrypted via TLS (HTTPS). This is non-negotiable in 2025. HTTPS protects visitors from:

• Man-in-the-middle (MITM) attacks — an attacker on the same network cannot intercept or modify the page content
• Content injection — ISPs and malicious networks cannot inject ads or malicious scripts into the page
• Credential sniffing — even though my site has no login, encrypted transport is a baseline expectation

My hosting provider (Manus) enforces HTTPS automatically, which means TLS certificates are provisioned and renewed without manual intervention — removing the human error risk of expired certificates.

Decision 3: No Unnecessary Data Collection

The contact form on my portfolio is intentionally minimal. It collects a name, email, and message — nothing more. I do not:

• Store form submissions in a database
• Use third-party tracking pixels
• Collect browser fingerprints or device data
• Set persistent tracking cookies

This follows the data minimisation principle from GDPR and ISO 27001 — only collect what you genuinely need. Less data collected means less data that can be breached, misused, or subpoenaed.

Decision 4: Content Security Policy (CSP) Awareness

A Content Security Policy is an HTTP header that tells browsers which sources of scripts, styles, and media are trusted. It is one of the most effective defences against Cross-Site Scripting (XSS) attacks.

For a static site like mine, the CSP is relatively simple — all assets are loaded from known CDN URLs and no inline scripts are executed. This means even if an attacker somehow injected a script tag into the HTML, a properly configured CSP would block it from executing.

Decision 5: Dependency Hygiene

My portfolio is built with React and a small set of well-maintained libraries. Every dependency is a potential supply chain risk — the npm ecosystem has seen numerous incidents where malicious packages were published under trusted names.

My approach:

• Use only widely-adopted, actively-maintained packages
• Pin dependency versions to avoid unexpected updates
• Regularly audit with npm audit to catch known vulnerabilities
• Avoid packages with excessive permissions or opaque ownership

This reflects the principle of least privilege applied to the software supply chain.

Decision 6: Social Links and Public Email

My email address is publicly visible on the portfolio. This is a deliberate trade-off — I want recruiters and collaborators to reach me easily. But it comes with risks:

• Spam and phishing — my address may be harvested by bots
• Targeted social engineering — knowing my email and role makes me a target

Mitigations I use:

• A dedicated professional email address (not my primary personal account)
• Strong spam filtering
• Awareness that any email claiming to be from a recruiter or employer deserves scrutiny

This is a real-world example of security vs. usability trade-offs — a concept central to GRC and security architecture roles.

What This Portfolio Demonstrates

Beyond showcasing my projects, this portfolio itself is a demonstration of security thinking:

1. Threat modelling before building — I identified risks before writing code
2. Architecture as a security control — static-first eliminates entire attack categories
3. Defence in depth — HTTPS + CSP + data minimisation + dependency hygiene work together
4. Principle of least privilege — minimal permissions, minimal data, minimal attack surface
5. Security vs. usability trade-offs — conscious decisions with documented reasoning

These are not just portfolio talking points. They are the same principles that drive decisions in SOC environments, GRC frameworks, and security architecture reviews.

Final Thoughts

Security is not a feature you bolt on after the fact. It is a mindset you bring to every decision from the very beginning. Building this portfolio taught me that even a simple personal website is an opportunity to practice and demonstrate that mindset.

If you are a cybersecurity student or professional building your own portfolio, I encourage you to think about your threat model first. Ask yourself: what am I protecting, from whom, and what is the cost of failure? The answers will guide every technical decision that follows.