API-Security-Checklist

KO | EN

gitlite — search

#typescript #ai-agents #ai #dsh-plugin #deepseek-harness #open-source #cli #claude-code #codex #developer-tools #react #windows

API-Security-Checklist

★ 23,299 Open GitHub ↗

API를 설계, 테스트, 배포할 때 꼭 확인해야 할 가장 중요한 보안 대응 조치 체크리스트

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# API 보안 체크리스트

API를 설계, 테스트, 배포할 때 꼭 알아야 할 가장 중요한 보안 대책 체크리스트입니다.

---

## 인증 (Authentication)

- [ ] `Basic Auth`를 사용하지 마세요. 대신 표준 인증을 사용하세요.
- [ ] `Authentication`, `token generation`, `password storage`를 직접 구현(재발명)하지 마세요. 표준을 사용하세요.
- [ ] 로그인 시 `Max Retry`와 계정 잠금(jail) 기능을 사용하세요.
- [ ] 모든 민감한 데이터에 암호화를 사용하세요.

## 접근 제어 (Access)

- [ ] DDoS / 무차별 대입(brute-force) 공격을 방지하기 위해 요청 제한(Throttling)을 사용하세요.
- [ ] MITM(중간자 공격)을 방지하고 `Host` 헤더가 SNI와 일치하는지 확인하기 위해, 서버 측에서 TLS 1.2+ 및 안전한 암호화 방식이 적용된 HTTPS를 사용하세요.
- [ ] SSL 스트립 공격을 방지하기 위해 SSL과 함께 `HSTS` 헤더를 사용하세요.
- [ ] 디렉터리 리스팅을 비활성화하세요.
- [ ] 비공개 API의 경우, 허용된(safelisted) IP/호스트에서만 접근을 허용하세요.

## 인가 (Authorization)

### OAuth

- [ ] 허용된 URL만 접근할 수 있도록 서버 측에서 항상 `redirect_uri`를 검증하세요.
- [ ] 토큰 대신 항상 코드로 교환하도록 하세요 (`response_type=token` 허용 금지).
- [ ] OAuth 인증 프로세스에서 CSRF를 방지하기 위해 랜덤 해시가 포함된 `state` 파라미터를 사용하세요.
- [ ] 기본 스코프를 정의하고, 각 애플리케이션에 대한 스코프 파라미터를 검증하세요.

## 입력 (Input)

- [ ] 작업에 맞는 적절한 HTTP 메서드를 사용하세요 (`GET (조회)`, `POST (생성)`, `PUT/PATCH (교체/수정)`, `DELETE (레코드 삭제)`). 요청된 리소스에 메서드가 적절하지 않은 경우 `405 Method Not Allowed`로 응답하세요.
- [ ] 지원하는 형식(예: `application/xml`, `application/json` 등)만 허용하도록 요청 Accept 헤더(콘텐츠 협상)에서 `content-type`을 검증하고, 일치하지 않으면 `406 Not Acceptable`로 응답하세요.
- [ ] 전송되는 데이터의 `content-type`을 허용된 형식에 맞춰 검증하세요 (예: `application/x-www-form-urlencoded`, `multipart/form-data`, `application/json` 등).
- [ ] 일반적인 취약점(예: `XSS`, `SQL-Injection`, `Remote Code Execution` 등)을 방지하기 위해 사용자 입력을 검증하세요.
- [ ] URL에 민감한 데이터(`credentials`, `Passwords`, `security tokens`, `API keys`)를 넣지 말고, 표준 Authorization 헤더를 사용하세요.
- [ ] 서버 측 암호화만 사용하세요.
- [ ] API Gateway 서비스를 사용하여 캐싱, 속도 제한 정책(예: `Quota`, `Spike Arrest`, `Concurrent Rate Limit`)을 활성화하고 API 리소스를 동적으로 배포하세요.

## 처리 (Processing)

- [ ] 손상된 인증 프로세스를 방지하기 위해 모든 엔드포인트가 인증으로 보호되어 있는지 확인하세요.
- [ ] 사용자의 리소스 ID를 직접 노출하지 마세요. `/user/654321/orders` 대신 `/me/orders`를 사용하세요.
- [ ] ID를 자동 증가시키지 마세요. 대신 `UUID`를 사용하세요.
- [ ] XML 데이터를 파싱하는 경우, `XXE`(XML 외부 엔티티 공격)를 방지하기 위해 엔티티 파싱이 활성화되어 있지 않은지 확인하세요.
- [ ] XML, YAML 또는 앵커와 참조를 사용하는 다른 언어를 파싱하는 경우, 지수적 엔티티 확장 공격을 통한 `Billion Laughs/XML bomb`을 방지하기 위해 엔티티 확장이 활성화되어 있지 않은지 확인하세요.
- [ ] 파일 업로드에는 CDN을 사용하세요.
- [ ] 대용량 데이터를 처리하는 경우, HTTP 차단을 방지하기 위해 가능한 한 백그라운드에서 Workers와 Queues를 사용하여 처리하고 빠르게 응답을 반환하세요.
- [ ] DEBUG 모드를 반드시 끄세요.
- [ ] 가능한 경우 실행 불가능한 스택(non-executable stacks)을 사용하세요.

## Output

- [ ] `X-Content-Type-Options: nosniff` 헤더를 전송하세요.
- [ ] `X-Frame-Options: deny` 헤더를 전송하세요.
- [ ] `Content-Security-Policy: default-src 'none'` 헤더를 전송하세요.
- [ ] 핑거프린팅 헤더(`X-Powered-By`, `Server`, `X-AspNet-Version` 등)를 제거하세요.
- [ ] 응답에 대한 `content-type`을 강제하세요. `application/json`을 반환하는 경우, 응답 `content-type`은 `application/json`이어야 합니다.
- [ ] 구현 세부 정보를 노출할 수 있는 지나치게 구체적인 에러 메시지를 클라이언트에 반환하지 말고, 일반적인 메시지를 사용하며 상세한 정보는 서버 측에만 로깅하세요.
- [ ] `credentials`, `passwords`, `security tokens`과 같은 민감한 데이터를 반환하지 마세요.
- [ ] 완료된 작업에 맞는 적절한 상태 코드를 반환하세요. (예: `200 OK`, `400 Bad Request`, `401 Unauthorized`, `405 Method Not Allowed` 등).

## CI & CD

- [ ] 단위/통합 테스트 커버리지를 통해 설계와 구현을 검증하세요.
- [ ] 코드 리뷰 프로세스를 사용하고 셀프 승인은 배제하세요.
- [ ] 벤더 라이브러리 및 기타 종속성을 포함하여, 프로덕션에 배포하기 전에 서비스의 모든 컴포넌트가 AV 소프트웨어에 의해 정적 스캔되었는지 확인하세요.
- [ ] 코드에 대한 보안 테스트(정적/동적 분석)를 지속적으로 실행하세요.
- [ ] 종속성(소프트웨어 및 OS 모두)에 알려진 취약점이 있는지 확인하세요.
- [ ] 배포를 위한 롤백 솔루션을 설계하세요.

## Monitoring

- [ ] 모든 서비스와 컴포넌트에 중앙 집중식 로깅을 사용하세요.
- [ ] 에이전트를 사용하여 모든 트래픽, 에러, 요청 및 응답을 모니터링하세요.
- [ ] SMS, Slack, Email, Telegram, Kibana, Cloudwatch 등을 통한 알림을 사용하세요.
- [ ] 신용카드, 비밀번호, PIN 등 어떠한 민감한 데이터도 로깅되지 않도록 하세요.
- [ ] IDS 및/또는 IPS 시스템을 사용하여 API 요청과 인스턴스를 모니터링하세요.

---

## See also:

- [yosriady/api-development-tools](https://github.com/yosriady/api-development-tools) - RESTful HTTP+JSON API를 구축하기 위한 유용한 리소스 모음입니다.
- JWT는 필요하지 않으며, 무작위로 생성된 API 키를 사용하세요. 비대칭 암호화나 변조 방지가 필요한 경우, [JWT의 대안들을 참고하세요](https://kevin.burke.dev/kevin/things-to-use-instead-of-jwt/).

---

## API Security Best Practices (Advanced)

### Rate Limiting & Abuse Prevention
- [ ] API 키 및 IP별 슬라이딩 윈도우 레이트 리미팅을 구현하세요.
- [ ] 반복되는 인증 실패 시도에 대해 지수 백오프(exponential backoff)를 적용하세요.
- [ ] 의심스러운 활동 이후 CAPTCHA 또는 작업 증명(proof-of-work) 챌린지를 구현하세요.
- [ ] 비정상적인 API 사용 패턴(시간, 볼륨, 엔드포인트)을 모니터링하고 경고를 설정하세요.

### GraphQL-Specific Security
- [ ] 프로덕션 환경에서는 인트로스펙션(introspection)을 비활성화하세요.
- [ ] 중첩 쿼리 공격을 방지하기 위해 쿼리 깊이 제한(query depth limiting)을 구현하세요.
- [ ] 리소스 고갈을 방지하기 위해 쿼리 비용 분석(query cost analysis)을 사용하세요.
- [ ] 가능하면 프로덕션에서 허용된 쿼리만 화이트리스트에 등록하세요.

### Secrets Management
- [ ] 정기적으로 API 키와 시크릿을 교체(rotate)하세요.
- [ ] 서명 작업에는 하드웨어 보안 모듈(HSM)을 사용하세요.
- [ ] CI/CD 파이프라인에서 시크릿 스캔을 구현하세요.
- [ ] 시크릿을 절대 버전 관리 시스템에 커밋하지 말고, 환경 변수나 시크릿 관리자를 사용하세요.

### Zero Trust Architecture
- [ ] 서비스 간 통신을 위해 상호 TLS(mTLS)를 구현합니다.
- [ ] 내부 서비스에서 오는 요청을 포함하여 모든 요청을 검증합니다.
- [ ] 자동 갱신 기능이 있는 수명이 짧은(short-lived) 토큰을 사용합니다.
- [ ] 민감한 작업에 대해 요청 서명을 구현합니다.

---

# Contribution

이 저장소(repository)를 포크(fork)하고, 일부 변경 사항을 만들어 풀 리퀘스트(pull request)를 제출하여 자유롭게 기여해 주세요. 문의 사항이 있으시면 `team@shieldfy.io`로 이메일을 보내주세요.

API-Security-Checklist

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README