java-auth-config-audit

Audit Java source code for authentication bypass, authorization flaws, and insecure security configurations.

1.7k|238|Updated Dec 7, 2019
One-click install
npx skills add https://github.com/wgpsec/AboutSecurity --skill java-auth-config-audit
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: java-auth-config-audit
Source: https://github.com/wgpsec/AboutSecurity/tree/main/skills/code-audit/java/java-auth-config-audit
Command: npx skills add https://github.com/wgpsec/AboutSecurity --skill java-auth-config-audit

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Java backend codebases frequently contain authentication bypasses, broken access control, weak cryptography, and information leaks that are hard to spot manually. This Skill provides a systematic white-box audit methodology covering six high-frequency vulnerability classes in Spring Boot, Spring Security, and Apache Shiro applications.

Core Features & Use Cases

  • Six Risk Categories: Covers authentication bypass (Spring Security/Shiro filter chain URI parsing differences), horizontal/vertical privilege escalation and IDOR, JWT security (algorithm confusion, hardcoded keys, missing claims validation), cryptographic misconfiguration (weak algorithms, hardcoded keys, insecure randomness), information disclosure (Actuator endpoints, error stacks, debug mode), and business logic flaws (race conditions, amount tampering, flow bypass).
  • Dangerous vs. Safe Code Patterns: Each vulnerability class includes concrete dangerous code snippets, secure remediation code, and EVID evidence templates for audit reports.
  • Search Keyword Index: Provides grep-ready keyword lists (e.g., SecurityConfig, Jwts.parser, Cipher.getInstance) to quickly locate audit entry points in large codebases.
  • Use Case: During a white-box review of a Spring Boot order system, use the checklist to find that the DAO layer query lacks a user_id filter (horizontal privilege escalation) and that Actuator endpoints are fully exposed, then document findings with the provided EVID templates.

Quick Start

Audit this Java project's Spring Security configuration and JWT handling code for authentication bypass and privilege escalation vulnerabilities, and report each finding with an EVID evidence record.

Frequently Asked Questions about java-auth-config-audit

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

FAQPage Schema
How do I audit Java code for authentication bypass vulnerabilities?

Start by examining Spring Security filter chain configurations for rule ordering issues where permitAll precedes stricter rules, and check Shiro filterChainDefinitionMap for URI parsing differences like trailing slashes or /..;/ sequences. Also review custom filters for early returns and loose whitelist matching such as startsWith checks.

How to detect horizontal privilege escalation in Java source code?

Check whether DAO or Mapper queries bind the current user ID, for example whether SELECT statements include AND user_id = #{currentUserId}. Controllers that accept an orderId path variable and query directly without ownership verification indicate horizontal privilege escalation.

What JWT vulnerabilities should I look for in Java code?

Look for algorithm confusion where parsers do not pin the algorithm, enabling RS256-to-HS256 or alg:none attacks, hardcoded SECRET_KEY values in source or application.yml, and missing validation of exp, iss, and aud claims. Refresh tokens without expiry or device binding are also common findings.

Does this audit approach cover Spring Boot Actuator exposure?

Yes, it covers Actuator misconfiguration including exposure.include set to wildcard, which exposes /env with credentials and /heapdump with memory contents. The remediation is restricting exposed endpoints and adding authentication via EndpointRequest matchers.

What are the limitations of static white-box auditing for business logic flaws?

Static review can identify non-atomic balance updates, client-supplied prices, and missing state machine checks, but confirming exploitability of race conditions typically requires dynamic concurrency testing. Findings should be validated with runtime reproduction where possible.