기능 개발이 끝났다고 바로 배포할 수 있는 건 아닙니다.

로그인, 게시판, 파일 업로드, 검색, 결제, 관리자 기능처럼 웹 서비스에는 다양한 입력과 권한이 들어가고, 작은 실수 하나가 보안 문제로 이어질 수 있습니다.

그래서 개발이 끝난 뒤에는 최소한 아래 항목 정도는 한 번씩 확인해보는 게 좋습니다.

1. 인증(Authentication)

먼저 로그인과 사용자 인증이 제대로 동작하는지 확인합니다.

• 로그인하지 않은 사용자가 보호된 페이지나 API에 접근할 수 없는지

• 비밀번호가 평문으로 저장되지 않는지

• 세션이나 JWT 만료가 정상적으로 동작하는지

• 로그아웃 후 기존 세션이나 토큰이 더 이상 사용되지 않는지

• 비밀번호 재설정 과정이 안전한지

중요한 서비스라면 MFA 적용도 고려할 수 있습니다.

2. 인가(Authorization) / IDOR

로그인했다고 해서 모든 데이터에 접근할 수 있는 것은 아닙니다.

예를 들어,

/users/100 /orders/200 /files/300

처럼 URL이나 요청에 ID가 포함된 경우, 숫자만 바꿔 다른 사용자의 데이터에 접근할 수 없는지 확인해야 합니다.

이런 문제를 흔히 IDOR이라고 합니다.

프론트 화면에서 버튼을 숨기는 것만으로는 부족하고, 실제 서버 API에서 권한을 검사해야 합니다.

3. SQL Injection

사용자가 입력한 값을 그대로 SQL 문자열에 붙이면 SQL Injection 문제가 발생할 수 있습니다.

특히 검색, 필터, 정렬, 로그인 같은 기능을 확인해야 합니다.

가능하면 ORM이나 Prepared Statement를 사용하고, 문자열을 직접 이어 붙여 SQL을 만드는 방식은 피하는 게 좋습니다.

4. XSS

게시글, 댓글, 이름, 검색어, 문의 내용처럼 사용자가 입력한 값이 화면에 다시 출력되는 곳은 XSS를 확인해야 합니다.

예를 들어 이런 값이 저장됐을 때,

<script>alert('xss')</script>

실제 브라우저에서 실행되면 문제가 됩니다.

입력값 검증뿐 아니라 화면에 출력할 때 Escape 처리가 제대로 되는지도 중요합니다

5. CSRF

Cookie 기반 로그인을 사용한다면 CSRF도 확인해야 합니다.

사용자가 로그인된 상태에서 악성 사이트에 접속했을 때, 본인도 모르게 중요한 요청이 실행되지 않도록 해야 합니다.

필요에 따라 SameSite Cookie나 CSRF Token 같은 방식을 사용할 수 있습니다.

6. 파일 업로드

파일 업로드 기능이 있다면 단순히 확장자만 확인해서는 부족합니다.

• MIME Type 확인

• 파일 크기 제한

• 실행 파일 업로드 차단

• 파일명 조작 방지

• Path Traversal 방지

• 업로드 파일이 서버에서 직접 실행되지 않는지

같은 부분을 확인해야 합니다.

7. Secret / 민감정보

DB 비밀번호, API Key, JWT Secret 같은 값이 코드나 Git에 포함되어 있지 않은지 확인합니다.

로그도 같이 확인해야 합니다.

비밀번호 Access Token Refresh Token API Key 개인정보

같은 값이 로그에 그대로 남지 않는 게 좋습니다.

8. CORS / Security Header

개발하면서 CORS를 너무 넓게 열어두지는 않았는지 확인해야 합니다.

운영 환경에서 특별한 이유 없이

Access-Control-Allow-Origin: *

처럼 설정되어 있다면 다시 확인하는 게 좋습니다.

필요하다면 CSP, HSTS, X-Content-Type-Options 같은 기본 Security Header도 같이 점검합니다.

9. Rate Limit

로그인, 인증번호 요청, 비밀번호 찾기, 검색 API처럼 반복 호출될 수 있는 기능은 Rate Limit이 필요한지 확인합니다.

예를 들어,

로그인 무한 시도 인증번호 반복 요청 특정 API 대량 호출 비밀번호 찾기 반복 요청

같은 공격이나 오남용을 막는 데 도움이 됩니다.

10. Dependency / Docker 취약점

직접 작성한 코드만 안전하다고 끝나는 것은 아닙니다.

사용하고 있는 라이브러리나 Docker Image에도 알려진 취약점이 있을 수 있습니다.

그래서 다음 항목도 주기적으로 확인하는 게 좋습니다.

Maven / Gradle Dependency npm Package Docker Base Image OS Package

취약점이 발견되면 가능한 범위에서 버전을 업데이트합니다.

11. 에러 처리

에러가 발생했을 때 서버 내부 정보가 사용자에게 그대로 노출되지 않는지도 확인해야 합니다.

예를 들어,

Stack Trace SQL Query 서버 내부 경로 DB 정보 Framework Version

같은 정보는 외부에 노출하지 않는 게 좋습니다.

사용자에게는 필요한 메시지만 보여주고, 상세 내용은 서버 로그에 남기는 방식이 일반적입니다.

12. 세션 / Cookie 보안

Cookie를 사용하는 경우 기본적인 보안 설정도 확인합니다.

HttpOnly Secure SameSite

같은 옵션이 적절하게 설정되어 있는지 확인하고, 세션이 지나치게 오래 유지되지는 않는지도 살펴봅니다.

13. 입력값 검증

프론트엔드에서 검증했다고 끝나는 게 아닙니다.

서버에서도 다시 검증해야 합니다.

예를 들어,

문자열 최대 길이 숫자 범위 필수값 날짜 형식 Enum 값 허용되지 않은 문자 예상하지 않은 JSON 필드

등을 확인할 수 있습니다.

프론트엔드 검증은 사용 편의를 위한 것이고, 보안을 위한 최종 검증은 서버에서 해야 합니다.

14. 불필요한 기능 노출

개발 과정에서 사용했던 기능이 운영 환경에 그대로 열려 있지는 않은지 확인합니다.

예를 들어,

Swagger Actuator Debug Endpoint 테스트 API 내부 관리 API 개발용 페이지

같은 기능입니다.

필요하지 않은 기능은 운영 환경에서 비활성화하거나 외부 접근을 제한하는 게 좋습니다.

가능한 부분은 자동으로 검증하자

보안 검증을 전부 사람이 눈으로 확인하면 빠뜨리는 항목이 생길 수 있습니다.

가능한 부분은 테스트나 보안 검사 도구로 자동화하는 게 좋습니다.

Build ↓ Unit Test ↓ Integration Test ↓ Authorization Test ↓ SAST ↓ Dependency Scan ↓ Container Scan ↓ PASS / FAIL

특히 인증과 인가처럼 중요한 규칙은 테스트 코드로 만들어두면 좋습니다.

@Test void 로그인하지않으면보호된API에접근할수없다() { // 인증 없이 API 호출 // 401 또는 403 확인 } @Test void 다른사용자의데이터에_접근할수없다() { // 다른 사용자의 데이터 요청 // 403 또는 404 확인 }

이렇게 만들어두면 나중에 기능을 수정하더라도 기존 보안 규칙이 깨졌는지 자동으로 확인할 수 있습니다.