azeezcode.com — application security portfolio

Project overview

AzeezCode is my professional application security and secure-development portfolio.

Rather than using a generic portfolio template, I built the website as a Laravel application so the site itself could demonstrate some of the security principles I discuss throughout my work.

The objective was to create a fast, maintainable and security-conscious portfolio for documenting application security case studies, secure development projects, authorised lab work and professional experience.

The application is deployed in production at azeezcode.com.

My responsibilities

I designed, developed, secured and deployed the application.

My responsibilities include:

• Laravel application architecture
• Blade templates and reusable components
• responsive frontend development
• file-based project and case-study content
• application security controls
• HTTP security-header configuration
• contact-form security
• abuse and spam protection
• production deployment
• Hostinger configuration
• vulnerability disclosure setup
• ongoing security review and hardening

Architecture

AzeezCode is a server-rendered Laravel application using Blade templates and reusable UI components.

Portfolio content such as projects, case studies and security material is stored as Markdown with structured front matter.

The current version deliberately avoids unnecessary application features.

There is:

• no public user registration
• no user account system
• no administration dashboard
• no database-backed content management system
• no public file-upload functionality

Reducing unnecessary functionality also reduces the application's exposed attack surface.

Only publicly required application files are exposed through the web-facing directory, while the main Laravel application remains outside the public document root.

Content Security Policy

The application implements a Content Security Policy through custom Laravel security middleware.

The policy is designed to restrict which resources the browser is permitted to execute or load.

The implementation uses request-specific nonces for permitted inline content rather than broadly allowing arbitrary inline script execution.

This provides an additional defence against certain cross-site scripting scenarios if unsafe content were ever introduced elsewhere in the application.

HTTP security headers

A custom Laravel security-header layer applies defensive browser policies including:

• Content-Security-Policy
• Strict-Transport-Security
• X-Content-Type-Options
• X-Frame-Options
• Referrer-Policy
• Permissions-Policy

These controls provide additional browser-side protection against issues such as content-type confusion, framing attacks, insecure transport downgrade and unnecessary browser capabilities.

Contact-form security

The contact form is the main public state-changing feature on the website, so several controls are applied around it.

These include:

• Laravel CSRF protection
• server-side validation
• bounded input lengths
• required consent
• per-IP rate limiting
• honeypot anti-spam protection
• minimum form-completion timing checks
• protection against malicious input reaching e-mail processing
• safe user-facing error handling

The form does not rely solely on client-side validation.

Security decisions are enforced server-side.

Rate limiting and abuse protection

Laravel's rate-limiting functionality is applied to the contact endpoint.

Requests are restricted on a per-IP basis to reduce automated abuse.

The form also contains a hidden honeypot field intended to detect simple automated submissions.

Timing checks provide another signal for submissions that are completed unrealistically quickly.

These controls are intended to reduce abuse without introducing unnecessary friction for legitimate visitors.

Input validation

Contact-form input is validated on the server.

Validation rules restrict expected fields and apply limits to the amount and type of data accepted by the application.

This follows a principle I use in application security work:

User-controlled input should never be trusted simply because it came from the application's own interface.

Requests can be modified outside the browser interface, so security controls must exist on the server.

CSRF protection

State-changing contact requests use Laravel's CSRF protection.

The server validates the CSRF token rather than assuming that a request originated from the legitimate form simply because it targets the correct endpoint.

This helps prevent another website from causing a visitor's browser to submit unwanted requests to the application.

Production error handling

Production configuration avoids exposing detailed framework errors and internal implementation information to visitors.

User-facing failures return controlled messages while diagnostic information remains server-side where appropriate.

Debugging is not intended to be exposed publicly in the production environment.

Secrets management

Sensitive configuration does not belong in the public repository.

Environment-specific values are stored through environment configuration rather than being hard-coded into application source files.

The repository can document the expected configuration structure without publishing production secrets.

Vulnerability disclosure

AzeezCode publishes a vulnerability disclosure contact at:

/.well-known/security.txt

The policy provides:

• a professional security contact
• the canonical disclosure location
• preferred language
• policy location
• defined scope
• prohibited/disruptive testing guidance
• responsible handling expectations

This gives security researchers a clear route for responsibly reporting a potential vulnerability affecting the site.

Responsible testing

I do not use this production portfolio as a deliberately vulnerable testing environment.

Security experiments and intentionally vulnerable applications belong in authorised training platforms or isolated lab environments.

This separation is important.

A professional portfolio should demonstrate defensive security engineering without intentionally exposing exploitable applications to the public internet.

Security verification

The security controls implemented on AzeezCode can be traced directly to the application code.

Examples include:

• security-header middleware
• Laravel rate-limiter configuration
• contact-request validation
• honeypot processing
• timing-based anti-spam checks
• CSRF middleware
• route-level throttling
• vulnerability disclosure configuration

This allows the portfolio to provide implementation evidence rather than simply listing security terminology.

Deployment architecture

The Laravel application code is stored outside the public web root.

The production document root exposes only files that need to be publicly accessible, including the Laravel entry point, compiled frontend assets, public images and selected static resources.

This reduces the risk of accidentally exposing application source files, configuration files or other internal project resources.

Secure development approach

Building AzeezCode has also been an opportunity to apply the same questions I use when reviewing other web applications:

• What input does the user control?
• Where is that input validated?
• Which endpoints change state?
• What prevents cross-site request forgery?
• What happens when requests are automated?
• What information is exposed in errors?
• Which files are publicly reachable?
• Which browser capabilities does the application actually require?
• Where are secrets stored?
• What happens if someone discovers a vulnerability?

Security is treated as part of application design rather than as a scanner run after development is complete.

Evidence and transparency

The portfolio intentionally distinguishes between:

• professional experience
• production development
• authorised security testing
• personal security projects
• training and lab exercises

I do not present training labs as client penetration tests or claim security controls that cannot be demonstrated.

As I complete additional AppSec labs and security-engineering projects, the portfolio will be expanded with sanitised evidence, remediation examples and technical case studies.

Lessons learned

• Reducing unnecessary functionality can be one of the most effective security controls.
• Security headers are useful as defence in depth, but they do not replace secure server-side application logic.
• CSRF protection and input validation belong on the server, regardless of what the browser interface permits.
• Public forms require both security controls and practical abuse protection.
• Production error handling should help operators diagnose problems without exposing implementation details to users.
• A vulnerability disclosure policy gives researchers a clear and professional way to report security issues.
• Security claims are much stronger when they can be demonstrated in the implementation.
• Building software and reviewing its security together produces better engineering decisions.