auditing-web-application-security

Orchestrates static and dynamic security audits of Spring and JSP web applications into unified reports.

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/bs-koo/gx-security --skill auditing-web-application-security-bs-koo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: auditing-web-application-security
Source: https://github.com/bs-koo/gx-security/tree/main/skills/auditing-web-application-security
Command: npx skills add https://github.com/bs-koo/gx-security --skill auditing-web-application-security-bs-koo

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? Security reviews of web applications often require running separate static scanners and manual penetration tests, then reconciling scattered results. This Skill unifies both phases into one orchestrated audit: it detects nine vulnerability classes (CSRF, XSS, SQLi, file upload, path traversal, broken access control, auth/session, sensitive data exposure, SSRF) from source code, filters false positives with AI context review, and optionally fires real payloads against a staging or local target to confirm exploitability. ## Core Features & Use Cases - Hybrid SAST + DAST orchestration: Runs scan_all.py for static candidate detection (Semgrep with grep fallback), then launches exploiting-* attack scripts against a live target when a URL is provided. - Fail-closed safety gates: scope_guard.py blocks production/public targets at code level, a DB isolation gate prevents polluting shared development databases, and destructive upload tests require explicit opt-in. - Credential hygiene: Passwords and tokens are passed via interactive environment variables (read -rs), never through chat, argv, or files. - Use Case: Before a release, point the Skill at a Spring Boot monorepo and a local staging URL; it auto-detects backend and frontend roots, audits all nine vulnerability classes, confirms IDOR and JWT issues with cross-account tests, and writes a severity-ranked four-element report (what, why, how, fix) to reports/. ## Quick Start Ask the AI to run a full security audit on your project source path with an optional local staging URL, for example: audit D:\SQ\my-project against http://localhost:8080 and produce a consolidated vulnerability report.

Frequently Asked Questions about auditing-web-application-security

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a full security audit on a Spring Boot project?▼

Run the audit script with your source path, optionally adding a target URL for dynamic testing: python audit.py <source> --target http://localhost:8080. Static scanning always runs; dynamic payload firing is opt-in after a scope and liveness check.

What vulnerability classes does this web security audit cover?▼

It covers nine classes: CSRF, XSS, SQL injection, file upload, path traversal, broken access control (IDOR/BFLA), authentication and session, sensitive data exposure, and SSRF with open redirect. Each class has dedicated detecting and exploiting modules.

Can I run penetration testing without Semgrep installed?▼

Yes, the static engine falls back to grep-based scanning when Semgrep is missing, but detection recall drops significantly and the scanner prints a fallback warning. Installing Semgrep via pip is recommended since zero candidates does not mean the code is safe.

Does the dynamic testing work against production servers?▼

No. The scope_guard.py tool validates the target host at code level and blocks production or public addresses; only staging and local targets pass. A DB isolation gate also prevents tests from polluting shared development databases with real data.

Why are some findings marked static-only instead of confirmed?▼

Classes like access control, auth/session, and SSRF need test accounts or injection points to fire real payloads. Without credentials (user A/B accounts or tokens) and targets, they remain static estimates; providing them via environment variables upgrades results to dynamically confirmed.

How are passwords handled during authenticated penetration tests?▼

Passwords and tokens are entered interactively with read -rs into environment variables and passed to child processes via env, never through chat, command-line arguments, or files. Only non-secret values like user IDs and resource IDs appear as plain arguments.