124 java secure coding
Plinth is an AI-native engineering toolkit for modern Java enterprise SDLC, built around reusable Commands, Agents, Skills, and MCP Servers.
npx -y skills add jabrena/plinth --skill 124-java-secure-codingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
Use when you need to apply Java secure coding best practices — including validating untrusted inputs, defending against injection attacks with parameterized queries, minimizing attack surface via least privilege, applying strong cryptographic algorithms, handling exceptions securely without exposing sensitive data, managing secrets at runtime, avoiding unsafe deserialization, and encoding output to prevent XSS. This should trigger for requests such as Review Java code for secure coding; Find input validation risks in Java code; Review Java code for injection vulnerabilities; Improve secure error handling in Java services; Harden Java code against common security flaws. Part of Plinth Toolkit
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.5 KB, as published. Nobody here has run it
Java Secure coding guidelines
Identify and apply Java secure coding practices to reduce vulnerabilities, protect sensitive data, and harden application behaviour against common attack vectors.
What is covered in this Skill?
- Input validation: type, length, format, and range checks
- SQL/OS/LDAP injection defence via
PreparedStatementand parameterized APIs - Attack surface minimisation: least-privilege permissions, removal of unused features
- Strong cryptography: BCrypt/Argon2 for passwords, AES-GCM for encryption, digital signatures; avoid deprecated ciphers (MD5, SHA-1, DES)
- Secure exception handling: log diagnostic details internally, expose only generic messages to clients
- Secrets management: load credentials from environment variables or secret managers — never hardcoded
- Safe deserialization: strict allow-lists, prefer explicit DTOs over native Java serialization
- Output encoding to prevent XSS in rendered content
Scope: The reference is organized by examples (good/bad code patterns) for each core area. Apply recommendations based on applicable examples.
Constraints
Before applying any secure coding changes, ensure the project compiles. If compilation fails, stop immediately — do not proceed until resolved. After applying improvements, run full verification.
- MANDATORY: Run
./mvnw compileormvn compilebefore applying any changes - SAFETY: If compilation fails, stop immediately — do not proceed until the project is in a valid state
- VERIFY: Run
./mvnw clean verifyormvn clean verifyafter applying improvements - BEFORE APPLYING: Read the reference for detailed good/bad examples, constraints, and safeguards for each secure coding pattern
When to use this skill
- Review Java code for secure coding
- Find input validation risks in Java code
- Review Java code for injection vulnerabilities
- Improve secure error handling in Java services
- Harden Java code against common security flaws
Workflow
- Compile project before secure-coding changes
Run ./mvnw compile or mvn compile and stop immediately if compilation fails.
- Read secure-coding reference and assess risks
Read references/124-java-secure-coding.md and identify applicable vulnerabilities and hardening opportunities.
- Apply secure-coding improvements
Implement selected protections for input validation, crypto, secrets, deserialization, and output encoding.
- Verify with full build
Run ./mvnw clean verify or mvn clean verify after applying improvements.
Reference
For detailed guidance, examples, and constraints, see references/124-java-secure-coding.md.