VulnScanner Pro: A Rule-Based Automated Web Application Vulnerability Assessment and Risk-Scoring System
Manual penetration testing needs specialist skills that most student developers and small teams simply don't have time to build, and the commercial DAST products that automate this work — Burp Suite Professional, Acunetix, Nessus — are priced for enterprise budgets rather than a college project or a solo developer's side application. Mature open-source alternatives such as OWASP ZAP close the cost gap but not the usability one: getting useful output still means learning how to configure a scan policy, spider a target, and read through a long list of raw findings. This paper describes VulnScanner Pro, a self-hosted assessment tool that tries to sit in the gap between those two extremes. It runs eight checks against a target URL — SQL injection, cross-site scripting, HTTP security-header analysis, SSL/TLS configuration, CSRF protection, WHOIS, IP geolocation, and Nmap-based port scanning — behind a FastAPI backend and a Next.js dashboard, storing every scan in SQLite so past results can be revisited later. A rule-based scoring function turns the combined module output into one 0–100 risk number and a CRITICAL/HIGH/MEDIUM/LOW label, and a matching recommendation engine looks up remediation text and reference links for whatever was found Active scanning of a system that you don’t own can be a legal problem as much as a technical one. So the API by default won’t start a scan of a system unless you explicitly pass in a consent flag and some text justification for why you are scanning the system. In a case study on a web application owned by the second author, the authors ran the full eight-module automated security assessment. It took about a minute to run the assessment and it reported a risk score of 20 out of 100 or LOW. The six checks for missing HTTP security headers were the only issues found. The checks for SSL/TLS, SQL injection, Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF) all reported that they found no issues. Only the two expected web ports (80 and 443) were open on the web application. The risk breakdown for the web application is shown below along with four recommendations for fixing the six missing HTTP security headers. Each of the recommendations are linked to authoritative external references for additional information on how to fix each of the issues found