Skill: java-secure-coding
Activation Contract
Use this skill when reviewing or designing Java code for secure coding practices: input validation, trust boundaries, injection, serialization/deserialization, sensitive data, resource exhaustion, mutability, access control, and third-party code risk.
Do not use this skill for full threat modeling, compliance audits, cryptography design, infrastructure hardening, or non-Java security work.
Responsibility
This skill teaches Java secure-coding review based on Java platform concerns and Oracle Secure Coding Guidelines. It does not call other skills, certify security, or replace a formal security review.
Required Context
- Data sources and trust boundaries.
- Inputs accepted and outputs generated.
- Sensitive data handled.
- Resource-intensive operations.
- Serialization, reflection, XML, SQL, command execution, or third-party dependencies involved.
Context Budget
- Keep this
SKILL.md focused on secure-coding decisions.
- Use
references/java-secure-coding-guidance.md for checklist details.
Hard Rules
- Establish trust boundaries before judging input safety.
- Validate and canonicalize untrusted input before use.
- Avoid dynamic SQL; use parameterized statements or safe higher-level APIs.
- Do not log secrets or expose sensitive data in exceptions.
- Release resources and defend against resource exhaustion.
- Treat deserialization, XML, reflection, JNDI, command execution, and third-party code as high-risk areas.
- Prefer least privilege and minimal accessibility.
Decision Gates
| Condition |
Action |
| Untrusted input crosses boundary |
Validate type, range, size, format, and canonical form. |
| SQL uses string concatenation |
Replace with parameterized query shape. |
| XML or deserialization is involved |
Require restrictive parser/filter configuration. |
| Sensitive data appears in logs/exceptions |
Remove, redact, or sanitize. |
| Resource size depends on input |
Add limits and overflow-safe checks. |
| Public/extensible surface exposes internals |
Reduce accessibility or document/guard contract. |
Execution Steps
- Identify trust boundaries and untrusted data.
- Check injection, inclusion, deserialization, and resource risks.
- Check sensitive-data exposure.
- Check mutability, access, and privilege boundaries.
- Return findings with severity and remediation.
Output Contract
Return:
- Secure-coding verdict:
low_risk, needs_hardening, or high_risk.
- Findings with severity and evidence.
- Recommended remediation.
- Residual risks and assumptions.
- Areas requiring formal security review, if any.
References
references/java-secure-coding-guidance.md — Java secure-coding checklist based on official guidance themes.
Assets
1---2name: java-secure-coding3description: Trigger: Java secure coding, Oracle Secure Coding Guidelines, input validation, trust boundaries, deserialization, least privilege, sensitive data. Review Java code for secure implementation practices.4license: MIT5---67# Skill: java-secure-coding89## Activation Contract1011Use this skill when reviewing or designing Java code for secure coding practices: input validation, trust boundaries, injection, serialization/deserialization, sensitive data, resource exhaustion, mutability, access control, and third-party code risk.1213Do **not** use this skill for full threat modeling, compliance audits, cryptography design, infrastructure hardening, or non-Java security work.1415## Responsibility1617This skill teaches Java secure-coding review based on Java platform concerns and Oracle Secure Coding Guidelines. It does not call other skills, certify security, or replace a formal security review.1819## Required Context2021- Data sources and trust boundaries.22- Inputs accepted and outputs generated.23- Sensitive data handled.24- Resource-intensive operations.25- Serialization, reflection, XML, SQL, command execution, or third-party dependencies involved.2627## Context Budget2829- Keep this `SKILL.md` focused on secure-coding decisions.30- Use `references/java-secure-coding-guidance.md` for checklist details.3132## Hard Rules3334- Establish trust boundaries before judging input safety.35- Validate and canonicalize untrusted input before use.36- Avoid dynamic SQL; use parameterized statements or safe higher-level APIs.37- Do not log secrets or expose sensitive data in exceptions.38- Release resources and defend against resource exhaustion.39- Treat deserialization, XML, reflection, JNDI, command execution, and third-party code as high-risk areas.40- Prefer least privilege and minimal accessibility.4142## Decision Gates4344| Condition | Action |45|---|---|46| Untrusted input crosses boundary | Validate type, range, size, format, and canonical form. |47| SQL uses string concatenation | Replace with parameterized query shape. |48| XML or deserialization is involved | Require restrictive parser/filter configuration. |49| Sensitive data appears in logs/exceptions | Remove, redact, or sanitize. |50| Resource size depends on input | Add limits and overflow-safe checks. |51| Public/extensible surface exposes internals | Reduce accessibility or document/guard contract. |5253## Execution Steps54551. Identify trust boundaries and untrusted data.562. Check injection, inclusion, deserialization, and resource risks.573. Check sensitive-data exposure.584. Check mutability, access, and privilege boundaries.595. Return findings with severity and remediation.6061## Output Contract6263Return:6465- Secure-coding verdict: `low_risk`, `needs_hardening`, or `high_risk`.66- Findings with severity and evidence.67- Recommended remediation.68- Residual risks and assumptions.69- Areas requiring formal security review, if any.7071## References7273- `references/java-secure-coding-guidance.md` — Java secure-coding checklist based on official guidance themes.7475## Assets7677- None.
andresnator