Introduction
When developing EdwinMolina.me, my professional portfolio, security was a top priority. To ensure the website remained secure against common vulnerabilities, I implemented a series of best practices guided by frameworks such as OWASP and MITRE ATT&CK. A key part of my security testing process involved using OWASP ZAP (Zed Attack Proxy), a widely trusted open-source tool for identifying security vulnerabilities in web applications.
In this post, I’ll dive into how I used OWASP ZAP to assess and secure my website, providing insights into the vulnerabilities discovered and the steps I took to mitigate them. Additionally, I’ll share valuable lessons learned throughout the process that will guide future security efforts.
What is OWASP ZAP?
OWASP ZAP is an open-source, dynamic application security testing (DAST) tool designed to identify security vulnerabilities in web applications during runtime. It is widely used by developers and security professionals to find weaknesses like:
- Cross-Site Scripting (XSS)
- SQL Injection
- Cross-Site Request Forgery (CSRF)
- Security Misconfigurations
- Sensitive Data Exposure
ZAP provides both automated and manual testing capabilities, making it a versatile tool for all levels of security testing. It integrates well into development pipelines, allowing for the identification of vulnerabilities during both the development and deployment phases of a web application.
Why OWASP ZAP for EdwinMolina.me?
As part of my commitment to building a secure platform, I needed a reliable tool to proactively test EdwinMolina.me for vulnerabilities. ZAP was the natural choice because of its:
- Comprehensive scanning capabilities
- Real-time analysis
- Support for OWASP Top Ten security risks
By using ZAP, I could scan my website for common issues and ensure early detection of vulnerabilities that could severely impact the security and functionality of the platform.
Running OWASP ZAP: The Process
I ran multiple ZAP scans on EdwinMolina.me at different stages of development. Below is the step-by-step process of how I used OWASP ZAP to identify and resolve vulnerabilities.
1. Initial Setup of OWASP ZAP
- Installed OWASP ZAP on my local machine.
- Configured ZAP to act as a proxy between my browser and the website, capturing all HTTP(S) traffic for analysis.
- Set up ZAP to scan the website’s endpoints for security weaknesses.
2. Automated Scanning
- Ran an automated scan to crawl the website’s pages and analyze HTTP requests and responses.
- Scanned both public and private sections of the website to ensure thorough coverage.
3. Manual Testing
- Conducted manual testing to fine-tune the results and validate vulnerabilities.
- Tested specific functionality, such as user authentication, form submission, and file uploads.
4. Vulnerability Review
- Reviewed the vulnerabilities reported by ZAP, categorized by severity levels: low, medium, and high risk.
- Prioritized issues based on their potential impact on the security of the website.
Key Vulnerabilities Discovered and Mitigated
ZAP identified 12 vulnerabilities in total:
- 3 medium-risk vulnerabilities
- 9 low-risk vulnerabilities
Here’s a breakdown of the key issues and how I addressed them:
Medium-Risk Vulnerabilities
-
Content Security Policy (CSP) Header Not Set
- Issue: Without a CSP header, the website was vulnerable to Cross-Site Scripting (XSS) attacks.
- Solution: Configured Apache to enforce a strict CSP header:
Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; frame-ancestors 'none';" - Result: Mitigated XSS risks by restricting resource loading.
-
Missing Anti-Clickjacking Header (X-Frame-Options)
- Issue: The website was susceptible to clickjacking attacks.
- Solution: Added the following configuration in Apache:
Header always set X-Frame-Options "DENY" - Result: Fixed the clickjacking vulnerability.
Low-Risk Vulnerabilities
-
Server Leaks Version Information
- Issue: The Apache server version was exposed in HTTP headers.
- Solution: Modified the Apache configuration to hide version information:
ServerTokens Prod ServerSignature Off - Result: Removed version information from HTTP responses.
-
Strict-Transport-Security (HSTS) Not Set
- Issue: The absence of HSTS left the site open to man-in-the-middle (MITM) attacks.
- Solution: Enabled HSTS in Apache:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" - Result: Enforced HTTPS connections, increasing security.
-
X-Content-Type-Options Header Missing
- Issue: The website was vulnerable to MIME-type sniffing.
- Solution: Added the X-Content-Type-Options header:
Header always set X-Content-Type-Options "nosniff" - Result: Protected the website from MIME-type sniffing attacks.
Conclusion
Conducting a comprehensive security assessment of EdwinMolina.me using OWASP ZAP provided valuable insights into potential vulnerabilities and allowed me to proactively mitigate security risks before they could be exploited. By addressing issues such as missing security headers, content security policy enforcement, and transport security configurations, I strengthened the overall resilience of the website against common attack vectors like XSS and clickjacking.
This hands-on experience reinforced my ability to identify, analyze, and remediate web application vulnerabilities using industry-standard tools and best practices such as OWASP Top Ten and MITRE ATT&CK. It also deepened my understanding of secure web server configurations, risk prioritization, and continuous security monitoring.
As cybersecurity threats continue to evolve, I remain committed to enhancing security postures through proactive testing, automation, and continuous learning. I look forward to applying these skills in a professional cybersecurity role, where I can help organizations harden their web applications and defend against real-world cyber threats.