Building and Securing My Portfolio Website on Azure

Why I Treated My Website Like a Security Project

I didn’t want my portfolio to be just a static website listing projects. I wanted it to function as a real-world cloud application. One that required deployment decisions, security controls, monitoring, and ongoing maintenance.

This site became a hands-on way to practice cloud security concepts in a realistic environment, where mistakes would surface quickly and defensive tooling would actually matter.

Architecture Overview

The application is a Python Flask web app containerized with Docker and deployed to Azure App Service. The goal was to keep the architecture intentionally simple while still exposing enough surface area to apply real security controls.

• Flask application running inside a Docker container
• Azure App Service used as the hosting platform
• Linux-based environment for deployment and troubleshooting
• TLS enforced using Azure-managed SSL certificates

Security Controls and Hardening Decisions

From the beginning, I assumed the application would be probed, misconfigured, or flagged by security tooling. Instead of avoiding that, I used it as feedback to improve the system.

Web Application Firewall (WAF)

Azure Web Application Firewall was configured with geo-blocking rules and managed rule sets to reduce unnecessary exposure. The goal wasn’t to block everything, but to limit obvious noise and observe how legitimate and illegitimate traffic behaved.

SSL and Transport Security

I configured both self-signed certificates during testing and Azure-managed SSL certificates in production. This helped reinforce the differences between local validation, cloud-managed certificates, and real deployment constraints.

Monitoring and Defender for Cloud Findings

Microsoft Defender for Cloud and Azure Security Center played an important role in this project. Rather than treating alerts as something to silence, I used them to understand where the platform expected stronger controls.

• Identifying missing security recommendations
• Reviewing flagged configurations and permissions
• Remediating issues related to network exposure and container configuration
• Using findings as validation rather than criticism

Why the Repository Is Private

The production infrastructure and deployment configuration for this site are intentionally kept private. This wasn’t a decision about secrecy, but rather a decision about realism.

Publishing infrastructure details, deployment credentials, and cloud configuration patterns would weaken the integrity of the system and encourage copy-paste deployments rather than thoughtful design.

Instead, the site itself serves as the artifact. The case studies, write-ups, and projects hosted here reflect the architecture, security decisions, and lessons learned without exposing sensitive implementation details.

Security is not a product, but a process.

What I Took Away From This Project

This project reinforced that even small applications benefit from disciplined security thinking. Cloud platforms provide powerful defaults, but those defaults only matter if you understand and validate them.

• Cloud security tooling is most valuable when treated as feedback, not noise
• Simple architectures are easier to secure and reason about
• Monitoring and remediation matter more than theoretical hardening
• A portfolio can double as a real security lab if designed intentionally

Going forward, this site will continue to evolve as both a portfolio and a living security project. Each new feature or deployment change is an opportunity to validate assumptions, improve defenses, and document lessons learned.