setrathexx/next-secure-check

next-secure-check is a security scanner aimed at Next.js projects. It looks through your code for common security mistakes before they reach production, things like committed secrets, unsafe API routes, missing rate limits on login or registration, weak configuration, XSS risks, raw SQL patterns, unsafe file uploads, and missing security headers. The README is explicit that the tool does not use AI at runtime, it works by matching deterministic rules against the source files. The scanner currently ships with 20 rules grouped by category (secrets, injection, xss, config, auth, headers, upload, validation). Each rule has its own documentation page. Examples include detecting committed .env files, hard-coded API keys, weak JWT secrets, use of eval or new Function, wildcard CORS origins, missing bcrypt or argon2 around password handling, raw SQL string concatenation, and Next.js-specific configuration gaps like productionBrowserSourceMaps being true or the poweredByHeader option not being switched off. There are three ways to use it. The command-line tool is installed from npm and run as next-secure-check scan . inside a project. Output formats include terminal text, JSON, Markdown, a GitHub Actions step summary, and SARIF for integration with code-scanning dashboards. The repository also runs the scanner in its own GitHub Actions workflow as a working example, writing a Markdown report to the job step summary and optionally failing the job when high or critical findings appear. A web demo at apps/web lets visitors scan public GitHub repositories by URL, that demo only does static analysis, never runs the scanned code, and does not touch private repositories. Configuration can be supplied through a .next-secure-check.json file at the project root, with fields for excluded paths, rule categories, the severity threshold to fail on, and the output format. Command-line flags override the config file, which overrides the defaults. The author describes the project as a first-year student learning project, currently at v0.1 with the MVP and hardening pass complete. They note that findings should be treated as review signals rather than proof of exploitation, and that false positives and false negatives are possible.