Security and API Checklist
This chapter defines the detailed checklist for the security and API areas of TQS-S/W certification. The security checklist verifies authentication/authorization, encryption, input validation, and vulnerability defense, while the API checklist verifies RESTful design rules, documentation, and error handling. Each item is classified as mandatory (O), recommended (R), or optional (S), with the verification method specified.
32.5.1. Security
The security checklist verifies the project's security implementation level. It covers core areas of software security including communication encryption, authentication/authorization, input validation, dependency security, and secret management.
| No. | Item | Classification | Verification Method |
|---|---|---|---|
| 1 | Communication is encrypted using TLS 1.2 or above | O | Server configuration verification |
| 2 | Passwords are stored as BCrypt hashes | O | Code review |
| 3 | Spring Security is applied | O | Verify dependencies in pom.xml and configuration files |
| 4 | Bean Validation is applied to validate input values | O | Code review |
| 5 | The v-html directive is not used (DOMPurify must be applied if unavoidable) | O | Code search |
| 6 | SQL parameter binding is used (no string concatenation) | O | Code review |
| 7 | Secrets are not hardcoded in source code (API keys, passwords, etc.) | O | Code search |
| 8 | OWASP Dependency-Check is applied to scan dependency security | R | Verify plugin in pom.xml |
| 9 | CORS (Cross-Origin Resource Sharing) policy is explicitly configured | O | Spring Security configuration verification |
| 10 | CSRF (Cross-Site Request Forgery) defense is implemented | O | Spring Security configuration verification |
| 11 | Security headers are configured (X-Frame-Options, X-Content-Type-Options, X-XSS-Protection) | R | Response header verification |
| 12 | Expiration policy is applied to sessions or tokens | O | Configuration file and code verification |
| 13 | Input value length restrictions are applied | O | Bean Validation annotation verification |
| 14 | Appropriate HTTP status code (403) is returned upon authorization failure | O | Code review |
| 15 | Sensitive information (passwords, tokens, etc.) is not output in logs | O | Code search |
The security area is the most strictly verified domain in TQS certification. Non-compliance with security items is a direct threat to the project's integrity, so mandatory items must be met. TLS (Transport Layer Security) application, password hashing, and SQL parameter binding are fundamental security requirements.
32.5.1.1. Security Verification Detailed Criteria
Security item verification applies the following detailed criteria.
- TLS 1.2 or above application is verified based on the production environment (prod) server configuration. HTTP may be permitted in development environments.
- A BCrypt hash cost factor of 10 or above is recommended.
- CORS configuration must not use wildcards (
*); allowed domains must be explicitly listed. - For CSRF defense in SPA architectures using token-based authentication, Spring Security's CSRF configuration must be appropriately configured.
32.5.2. API Design
The API design checklist verifies RESTful API design rules, documentation level, and error handling standards.
| No. | Item | Classification | Verification Method |
|---|---|---|---|
| 16 | RESTful URL naming conventions are followed (noun-based, plural, kebab-case) | O | API endpoint list verification |
| 17 | Standard error response format is applied (error code, message, timestamp) | O | API response structure verification |
| 18 | SpringDoc (Swagger UI) is applied for API documentation | O | Verify dependencies in pom.xml and Swagger UI access |
| 19 | ISO 8601 format is used for dates and times | O | API request/response sample verification |
| 20 | Pagination standards are applied (page, size, totalElements, totalPages) | O | API response structure verification |
| 21 | API versioning strategy is applied (URL path or header approach) | R | API endpoint list verification |
| 22 | Request and response examples are included in API documentation | R | Swagger UI verification |
| 23 | Rate Limiting is applied to restrict API calls | R | Configuration file or code verification |
| 24 | HTTP methods are used correctly (GET for retrieval, POST for creation, PUT for update, DELETE for deletion) | O | API endpoint list verification |
| 25 | Appropriate HTTP status codes are returned (200, 201, 204, 400, 404, 500, etc.) | O | API response verification |
The API design area is a core element that determines interoperability with external systems and developer experience. Consistent application of RESTful conventions and API documentation through SpringDoc are mandatory requirements.
32.5.2.1. API Design Verification Detailed Criteria
API design item verification applies the following detailed criteria.
- RESTful URLs must express resources as plural nouns (e.g.,
/api/users,/api/products). - Verbs must not be used in URL paths (e.g.,
/api/getUsersis not permitted). - Standard error responses must include at minimum the
code,message, andtimestampfields. - The ISO 8601 date format follows the
yyyy-MM-dd'T'HH:mm:ss.SSSZpattern. - Pagination responses must include the
page,size,totalElements, andtotalPagesfields.
32.5.3. Item Summary
The total number of items and distribution by classification for the security and API checklist are as follows.
| Area | Mandatory (O) | Recommended (R) | Optional (S) | Total |
|---|---|---|---|---|
| Security | 12 | 3 | 0 | 15 |
| API Design | 7 | 3 | 0 | 10 |
| Total | 19 | 6 | 0 | 25 |
The security and API checklist consists of a total of 25 items. All 19 mandatory items must be met to obtain Basic certification, and the compliance rate of the 6 recommended items determines whether the Advanced or Premier certification grade is achieved.
The reason the mandatory item ratio in the security area is 80%, higher than other areas, is that security vulnerabilities have a critical impact on the reliability of the entire service.
32.5.4. Security Verification Notes
The following points must be observed when verifying the security checklist.
- Security items are verified through a combination of automated verification and manual review. Items detectable by tools (hardcoded secrets, SQL string concatenation, etc.) are verified through automated verification first.
- If OWASP Dependency-Check scan results reveal vulnerabilities with a CVSS (Common Vulnerability Scoring System) score of 7 or above, a resolution or mitigation plan for the vulnerability must be provided.
- Security header configuration is verified based on production environment (prod) response headers. In development environments (local/dev), some headers may be disabled for debugging convenience.
- Secret management must be performed through environment variables or external secret management tools, and it must be verified that
.envfiles are included in.gitignore.
32.5.5. API Verification Notes
The following points must be observed when verifying the API checklist.
- API documentation is verified based on the Swagger UI auto-generated by SpringDoc. Separately hand-written documentation is not accepted.
- Rate Limiting application is verified based on production environment (prod) configuration. Rate Limiting may be disabled in development environments.
- Both URL path-based versioning (
/api/v1/) and header-based versioning are permitted for API versioning. One approach must be consistently applied within the project. - Pagination standards apply only to list retrieval APIs. They do not apply to single-item retrieval APIs.