Security Misconfigurations
Security misconfiguration is the most commonly found vulnerability class in web applications, arising from default credentials, unnecessary features, verbose error messages, and missing security headers. You will learn a systematic approach to identifying misconfigurations across web servers, application frameworks, and cloud environments. Many high-profile breaches have resulted from simple misconfigurations rather than sophisticated exploits.
Learning Objectives — Deep Dive
Each objective below is broken down into plain English so you know exactly what you are learning, why it matters, and what you will be able to do when you are done. Mark each one complete as you work through the lesson.
Test all HTTP methods
Use Burp Suite or curl to send requests to a target endpoint using every HTTP method: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, and TRACE. Start with OPTIONS to discover which methods the server advertises as allowed — the response's Allow header lists them. Then test each method individually, even those not listed in Allow, because servers sometimes accept methods they do not advertise. A common finding is that PUT or DELETE is accepted on endpoints that should be read-only, allowing an attacker to modify or delete resources without authorization.
Check for default credentials
Identify all administrative interfaces on the target — web admin panels, database management tools (phpMyAdmin), CMS admin pages (/wp-admin, /administrator), and network device interfaces. For each interface, attempt login with the most common default credential pairs: admin/admin, admin/password, admin/blank, root/root, and the application name as both username and password. Maintain a reference list from resources such as default-password.info and cirt.net/passwords. Default credentials are one of the most common findings in real penetration tests because administrators frequently forget to change them after initial setup.
Enumerate hidden paths
Run 'gobuster dir -u http://<target> -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txt' to discover hidden directories and files on the web server. Pay special attention to paths such as /admin, /backup, /config, /.git, /api, and /test — these frequently contain sensitive functionality or exposed data. A .git directory accessible from the web is a critical finding because it allows an attacker to download the entire application source code using 'git clone'. Also check for backup files such as config.php.bak or database.sql that may have been left on the server.
Check HTTP security headers
Use curl -I http://<target> or the browser's developer tools Network tab to inspect the HTTP response headers. Check for the presence and correct configuration of security headers: Content-Security-Policy (prevents XSS), X-Frame-Options (prevents clickjacking), X-Content-Type-Options: nosniff (prevents MIME sniffing), Strict-Transport-Security (enforces HTTPS), and Referrer-Policy. Use the online tool securityheaders.com to get a graded report of a site's header configuration. Missing or misconfigured security headers are low-to-medium severity findings that are easy to document and remediate.
Run Nikto
Run 'nikto -h http://<target>' to perform an automated web server vulnerability scan. Nikto checks for over 6,700 potentially dangerous files and programs, outdated server software, version-specific problems, and server configuration issues. The scan typically takes 5–15 minutes and produces a list of findings with descriptions and references. Do not treat Nikto output as definitive — it produces false positives, and each finding must be manually verified before including it in a report. Use Nikto as a checklist generator rather than a definitive vulnerability scanner.