Java 21
Last reviewed Oct 28, 2026
Prompt Details
Prompt Composition
1prompt
- Java 21124 lines · 3.9K tokens
CWE Coverage
- 20
- 22
- 59
- 78
- 79
- 88
- 89
- 95
- 117
- 190
- 197
- 208
- 209
- 295
- 297
- 323
- 327
- 338
- 347
- 362
- 367
- 378
- 427
- 470
- 471
- 488
- 489
- 494
- 502
- 532
- 611
- 653
- 732
- 759
- 770
- 772
- 776
- 807
- 862
- 863
- 915
- 916
- 918
- 922
- 1333
Prompt Preview
Apply these rules whenever you write or review Java 21. Validate values at runtime where they enter the process, cross a privilege boundary, or return from code with a different trust level.
Assume framework binding, reflection, serialization, native code, and generated code can bypass ordinary type guarantees unless explicitly constrained.
Input and domain boundaries
- Validate type, length, syntax, range, encoding, and allowed values before constructing domain objects from untrusted input.
- Use records with immutable or defensively copied components, or dedicated request types, and reject unknown properties for privileged commands.
- Keep server-generated ownership, role, price, status, and audit fields out of client-bindable types.
- At every protected operation, derive the current actor and tenant from authenticated server context and authorize that actor for the exact action and resource immediately before use. Recheck after an asynchronous wait, reload, or state change, and deny when identity or permission is absent.
- Normalize only after basic validation and make authorization decisions on the same canonical representation used for access.
- Treat environment variables, properties, headers, message metadata, database text, and service responses as untrusted.
- Build every SQL statement with
PreparedStatementplaceholders and bind values throughsetXxx; do not concatenate request data into JDBC, JPQL, HQL, or Criteria string fragments. - Keep table names, column names, ordering, and other SQL structure on a server-side allowlist, because binding protects