T09 · Insecure Skill Coding Practices
Error
- Location
- references/backend-layers.md:231
- Finding
- Reusable API Templates Omit Authorization Checks on Detail and Export Endpoints<![CDATA[ ## Vulnerability Details **File Location**: `references/backend-layers.md:231-236` and `references/backend-layers.md:251-258` **Vulnerability Type**: Missing method-level authorization in reusable API templates **Risk Level**: High ### Vulnerable Code ```java // 详情 @GetMapping(value = "dictionary/{dictId}") @Encrypt public ResponseEntity<BaseDictionaryVo> getInfo(@PathVariable Long dictId) { BaseDictionaryDto dto = baseDictionaryService.getDtoById(dictId); return success(BaseDictionaryVo.DTO.apply(dto)); } ``` ```java // 导出：ExcelUtil 泛型 @PostMapping("dictionary/export") @Encrypt public void export(HttpServletResponse response, BaseDictionaryVoParam param) { Page<BaseDictionaryDto> result = baseDictionaryService.getPageDto(param.toModelParam()); List<BaseDictionaryVo> vos = Lists.transform(result.getResult(), BaseDictionaryVo.DTO); ExcelUtil<BaseDictionaryVo> util = new ExcelUtil<>(BaseDictionaryVo.class); util.exportExcel(response, vos, "字典类型"); } ``` ### Technical Analysis The detail and export endpoint templates do not include `@PreAuthorize` checks. This is inconsistent with the Skill's stated requirement that every controller endpoint carry an explicit permission check and with its documented permission format: ```java @PreAuthorize("@ss.hasPerms('{domain}:{entity}:{action}')") ``` The `@Encrypt` annotation only concerns response protection; it does not establish whether the caller is authorized to access the underlying data. Consequently, applications copied or generated from these templates may expose the endpoints to users who do not hold the corresponding business permissions. The actual exploitability depends on the consuming application's global Spring Security configuration. If global route rules only require authentication, or permit these routes without method-level authorization, any user satisfying those broader rules could invoke the affected operations. ### Attack Path 1. A developer copies the docum ...[truncated 1546 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Add explicit permission checks to both templates: ```java @GetMapping(value = "dictionary/{dictId}") @PreAuthorize("@ss.hasPerms('system:dictionary:detail')") @Encrypt public ResponseEntity<BaseDictionaryVo> getInfo(@PathVariable Long dictId) { BaseDictionaryDto dto = baseDictionaryService.getDtoById(dictId); return success(BaseDictionaryVo.DTO.apply(dto)); } ``` ```java @PostMapping("dictionary/export") @PreAuthorize("@ss.hasPerms('system:dictionary:export')") @Encrypt public void export(HttpServletResponse response, BaseDictionaryVoParam param) { Page<BaseDictionaryDto> result = baseDictionaryService.getPageDto(param.toModelParam()); List<BaseDictionaryVo> vos = Lists.transform(result.getResult(), BaseDictionaryVo.DTO); ExcelUtil<BaseDictionaryVo> util = new ExcelUtil<>(BaseDictionaryVo.class); util.exportExcel(response, vos, "Dictionary Type"); } ``` 2. Review every reusable controller example and generator template to ensure list, detail, save, update, delete, and export operations each require an operation-specific permission. 3. Configure Spring Security to deny access by default so that an accidentally omitted method annotation does not expose a route. 4. Add automated authorization tests for every endpoint. Verify that: - Requests without authentication are rejected. - Authenticated users without the required permission receive HTTP 403. - Only users with the exact operation-specific permission can retrieve or export data. 5. Apply data-scope authorization in addition to endpoint authorization where users are permitted to access only records belonging to their organization, department, tenant, or ownership scope. 6. Add a static-analysis or review rule that flags controller methods lacking `@PreAuthorize` or an explicitly documented alternative authorization mechanism. ]]>