Skip to content
Back to skills

Java Security

ASecurity

trigger: writing Java or Kotlin (Spring, Jakarta EE, Quarkus, Android), SQL/JPA/MyBatis, templates, application.properties/.yml, web.xml, pom.xml, Gradle; \"customize java security\" opens the guided page. avoid: injection, XXE, SSRF, unsafe deserialization, path traversal, weak crypto, trust-all TLS, Spring Security off, exposed secrets, known-exploited deps, SpotBugs/Sonar/PMD/Checkstyle findings. 129 rules, 16 packs, each allow|deny|ask in .chock/security.json; absent = deny (quality: allow).

  • 3 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 23, 2026
ai-agentsrustgojavakotlinshellsqlspringtestinggitsecurity

Works with

  • cli
  • mcp

Security analysis

A100/100

Pro scans all 3 files and shows the line behind each finding

Scanned October 2, 2026

npx -y skills add open-coder-ai/chock-catalog --skill java-security --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Java Security?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Java Security
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/open-coder-ai-java-security/badge)](https://www.skillsdirectory.com/skills/open-coder-ai-java-security)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: java-security
description: "trigger: writing Java or Kotlin (Spring, Jakarta EE, Quarkus, Android), SQL/JPA/MyBatis, templates, application.properties/.yml, web.xml, pom.xml, Gradle; \"customize java security\" opens the guided page. avoid: injection, XXE, SSRF, unsafe deserialization, path traversal, weak crypto, trust-all TLS, Spring Security off, exposed secrets, known-exploited deps, SpotBugs/Sonar/PMD/Checkstyle findings. 129 rules, 16 packs, each allow|deny|ask in .chock/security.json; absent = deny (quality: allow)."
metadata:
  chock.artifact: hook
  chock.enforcement: block
  chock.coverage_without_chock: advisory
---

# Java Security Rules

trigger: writing Java or Kotlin (Spring, Jakarta EE, Quarkus, Android), SQL/JPA/MyBatis, templates, application.properties/.yml, web.xml, pom.xml, Gradle; "customize java security" opens the guided page. avoid: injection, XXE, SSRF, unsafe deserialization, path traversal, weak crypto, trust-all TLS, Spring Security off, exposed secrets, known-exploited deps, SpotBugs/Sonar/PMD/Checkstyle findings. 129 rules, 16 packs, each allow|deny|ask in .chock/security.json; absent = deny (quality: allow).

```
on(commit|tool_use): block(script) script=java-security-gate.py
java-security: a construct one of its rules denies -- the refusal above names the rule, the pack it belongs to and the fix. Each rule's verdict is allow|deny|ask in .chock/security.json, per rule or per pack (java, crypto, spring, jakarta, persistence, templates, logging, build, android, bugs, concurrency, resources, exceptions, performance, style, testing); absent = deny for a security pack, allow for a quality pack (bugs through testing). Only what the change adds is refused: a violation on lines the change leaves alone never blocks it. Only a human reviewer waives a line, with // chock: allow <rule-id>, never the agent: in the agent a waiver counts once a human has committed it. Choose verdicts by asking to customize java security, which opens this skill's guided page.
```

## Guided setup

Asked to customize, configure, set up, review or change these rules -- "customize java
security" and anything meaning it -- open the guided page rather than asking the questions
as prose. Open it unasked, once, when Java is about to be written and no selection file
exists at either scope: every security rule denies until someone chooses (a quality pack's
rules allow), and the page is a better first meeting than the refusal. It is `setup.html`, in
this skill's own directory beside this file and `references/`. It is offline and writes
nothing itself; each rule's pack default is preselected (deny for a security pack, allow for
a quality pack), and a verdict is chosen, never derived from a question about the stack. It
asks once per pack -- java, crypto, spring, jakarta, persistence, templates, logging, build,
android, then the quality packs -- so a team switches off a stack it does not run in one
answer, and opens a pack's rules only when asked.

Where this client can publish an Artifact, publish that file as one, declaring
`capabilities: {db: {}}`, and let the person walk it in the panel. Their Submit writes the
result to the artifact's own store at `selection/current`; read that document back.
Everywhere else, open the page in a browser and take the result from their clipboard.

`result.selection` is the whole file and `result.wiring.scope` says where it goes. The file
sets each rule's verdict, so the person writes it from their own shell, never the agent:
protect-agent-config refuses an agent's write to either path.

- `repo`: `.chock/security.json` at the repository root, committed; where chock is
  installed there, `chock sync --repo .` afterwards.
- `user`: `~/.chock/security.json`, the floor for work outside a repository that carries its
  own. A repository carrying `.chock/security.json` governs itself: give no user-scope
  command, say so, and offer the repo-scope one for a pull request instead.

Show the person one row per rule, the whole resulting file and, where a selection exists,
the diff against it. Then give one command to paste into their own shell, and never run it:

    mkdir -p .chock && cat > .chock/security.json <<'EOF'
    <result.selection, as indented JSON>
    EOF

(`~/.chock` in both places for user scope.) Never put a pattern, severity or path in the file:
it carries verdicts only, and the gate refuses anything else at the next write. Reach for the
text walk -- `references/setup-contract.json`, one rule at a time, its pack's `default` unless told
otherwise -- only where the page cannot be shown at all.

## Plan-time guidance

Before writing Java, call `chock_guidance` with your plan and the repo-relative paths you will
touch, where this client has that tool (`chock mcp`, served by chock, read-only, local). It
names the rules this repo's selection sets to deny or ask that the plan touches, each with its
constraint text. An empty answer is not a clearance: the gate still judges the code.

Wiring is not this skill's. Installed as a plugin, the hooks beside this file judge each
write and the turn's end; in a repository, `chock sync` adds the commit hook. Both read the
same selection file.

This skill is advisory: the client reading it has no mechanism to enforce it. The same policy compiled by `chock` blocks at commit, on an agent's file writes and at turn end. See https://github.com/open-coder-ai/chock

Files in this skill

  • SKILL.md3.9 KB
  • references/setup-contract.json5.7 KB
  • setup.html42.3 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…