웹 보안
더 많은 작업
웹 보안(Web Security)은 웹사이트와 웹 애플리케이션, 웹 API 및 이를 운영하는 서버·네트워크·클라우드 환경을 사이버 공격과 비인가 접근으로부터 보호하여 정보의 기밀성·무결성·가용성을 확보하는 기술과 관리 활동이다.
웹 보안은 인터넷을 통해 제공되는 웹서비스의 안전성을 확보하기 위한 정보보안 분야이다. 웹 서버와 애플리케이션의 취약점을 제거하는 것뿐 아니라 사용자 인증, 접근권한 관리, 통신 암호화, 데이터 보호, 소프트웨어 공급망 관리 및 침해사고 탐지·대응까지 포함한다.
웹서비스는 외부 사용자의 요청을 처리해야 하므로 다양한 공격에 노출된다. 공격자는 입력값 검증 오류, 인증·인가 결함, 서버 설정 오류, 취약한 라이브러리 및 업무 처리 절차의 허점을 악용하여 정보를 유출하거나 서비스를 중단시킬 수 있다.
웹 보안은 이러한 위험을 예방하고, 공격이 발생하더라도 피해를 제한하며, 사고를 신속하게 탐지하고 복구하는 것을 목표로 한다.
국제 비영리단체 OWASP(Open Worldwide Application Security Project)는 웹 애플리케이션의 주요 보안 위험을 정리한 OWASP Top 10과 보안 요구사항 검증을 위한 ASVS(Application Security Verification Standard), 웹 보안 테스트 지침인 WSTG(Web Security Testing Guide) 등을 제공한다.[1]
| 항목 | 내용 |
|---|---|
| 영문 명칭 | Web Security |
| 주요 보호 대상 | 웹사이트, 웹 애플리케이션, 웹 API, 웹 서버, 사용자 계정, 데이터베이스 |
| 보안 목표 | 기밀성, 무결성, 가용성, 인증, 인가, 책임추적성 |
| 주요 위협 | SQL 인젝션, XSS, CSRF, SSRF, 계정 탈취, 접근통제 우회, 서비스 거부 공격 |
| 주요 보호기술 | HTTPS/TLS, WAF, MFA, 접근통제, 입력 검증, 출력 인코딩, 보안 로깅 |
| 관련 지침 | OWASP Top 10, OWASP ASVS, OWASP WSTG, NIST SSDF |
| 주요 점검 방법 | 코드 검토, SAST, DAST, SCA, 모의해킹, 퍼징 |
| 적용 영역 | 웹 개발, 시스템 운영, 클라우드 보안, API 보안, DevSecOps |
기밀성(Confidentiality)은 권한이 없는 사용자가 정보에 접근하거나 정보를 취득하지 못하도록 보호하는 성질이다.
웹서비스에서 기밀성 보호 대상에는 개인정보, 인증정보, 금융거래정보, 기업의 영업비밀 및 시스템 내부 설정정보 등이 포함된다.
기밀성 확보에는 통신 암호화와 저장 데이터 암호화, 접근통제, 비밀정보 관리 및 권한 최소화 등이 활용된다.
무결성(Integrity)은 정보가 승인되지 않은 방식으로 변경되지 않도록 보장하는 성질이다.
웹서비스에서 무결성이 훼손되면 공격자가 게시물이나 거래정보를 변조하거나, 정상적인 프로그램 파일을 악성코드로 교체할 수 있다.
무결성 확보에는 접근통제, 전자서명, 메시지 인증코드, 안전한 배포 절차 및 변경 이력 관리 등이 활용된다.
가용성(Availability)은 정당한 사용자가 필요한 시점에 서비스와 정보에 접근할 수 있도록 보장하는 성질이다.
웹서비스의 가용성은 분산 서비스 거부 공격(DDoS), 서버 장애, 데이터베이스 장애, 과도한 자원 사용 및 클라우드 인프라 장애 등에 의해 영향을 받을 수 있다.
가용성 확보에는 트래픽 분산, 자원 제한, 장애 복구, 백업, 이중화 및 DDoS 방어 등이 활용된다.
최소 권한(Least Privilege)은 사용자와 서비스 계정, 프로그램에 업무 수행에 필요한 최소한의 권한만 부여하는 원칙이다.
예를 들어 웹 애플리케이션이 데이터베이스에서 특정 테이블의 정보를 조회하기만 한다면, 해당 계정에 데이터베이스 전체에 대한 관리자 권한을 부여할 필요는 없다.
최소 권한은 취약점이 악용되었을 때 공격자가 수행할 수 있는 행위와 피해 범위를 제한하는 데 도움이 된다.
심층 방어(Defense in Depth)는 하나의 보안기술에만 의존하지 않고 여러 보호수단을 조합하는 원칙이다.
예를 들어 웹서비스는 안전한 입력 처리와 접근통제, WAF, 네트워크 분리, 최소 권한 및 보안 로깅을 함께 적용할 수 있다.
이 경우 일부 보안 통제가 우회되더라도 다른 통제가 피해를 줄일 수 있다.
다만 여러 보안제품을 도입했다는 사실만으로 심층 방어가 완성되는 것은 아니다. 각 보호수단의 역할과 적용 범위, 상호 의존성을 검토해야 한다.
안전한 기본값(Secure by Default)은 사용자가 별도의 보안 설정을 수행하지 않더라도 서비스가 가능한 한 안전한 상태로 제공되도록 설계하는 원칙이다.
불필요한 기능과 권한은 기본적으로 비활성화하고, 공개 접근이 필요한 자원만 명시적으로 허용하는 방식이 대표적이다.
웹서비스는 일반적으로 사용자 브라우저, DNS, CDN, 로드 밸런서, 웹 서버, 애플리케이션 서버 및 데이터베이스 등으로 구성된다.
서비스의 규모와 기술구조에 따라 일부 구성요소는 생략되거나 통합될 수 있다.
웹서비스의 보안은 개별 서버의 안전성뿐 아니라 구성요소 사이의 통신과 인증, 권한 및 데이터 흐름에 영향을 받는다.
| 구성요소 | 주요 보안 위험 | 주요 보호수단 |
|---|---|---|
| 브라우저 | XSS, 세션 탈취, 악성 스크립트 | CSP, 안전한 DOM 처리, 쿠키 보호 |
| DNS | DNS 변조, 도메인 탈취 | 등록기관 계정 보호, DNSSEC, 변경 감시 |
| CDN | 캐시 오염, 설정 오류, 원본 서버 노출 | 캐시 정책 검증, 원본 접근 제한 |
| 로드 밸런서 | TLS 설정 오류, 잘못된 요청 전달 | TLS 정책, 헤더 검증, 접근통제 |
| 웹 서버 | 취약한 소프트웨어, 불필요한 기능 노출 | 보안 패치, 하드닝, 최소 권한 |
| 애플리케이션 서버 | 인젝션, 인증·인가 오류, 업무 로직 취약점 | 시큐어 코딩, 서버 측 권한 검증 |
| 데이터베이스 | 비인가 조회·변경, 계정 탈취 | 최소 권한, 암호화, 접근통제 |
| 외부 API | 자격증명 유출, 공급망 위험, 응답 데이터 악용 | 인증, 입력 검증, 호출 제한 |
신뢰 경계(Trust Boundary)는 서로 다른 보안 신뢰 수준을 가진 구성요소 사이의 경계이다.
대표적인 신뢰 경계에는 인터넷과 내부망, 브라우저와 서버, 일반 사용자와 관리자, 애플리케이션과 데이터베이스, 조직 내부 시스템과 외부 서비스 등이 있다.
웹서비스는 신뢰 경계를 통과하는 데이터와 요청에 대해 적절한 검증을 수행해야 한다.
특히 클라이언트에서 전달하는 사용자 식별자나 권한정보를 서버가 그대로 신뢰하는 방식은 위험하다.
프런트엔드(Frontend)는 사용자의 브라우저에서 실행되는 화면과 클라이언트 측 프로그램을 의미한다.
백엔드(Backend)는 서버에서 인증과 업무 처리, 데이터 저장 및 외부 시스템 연동 등을 수행하는 부분이다.
프런트엔드에서 입력값을 검사하거나 관리자 버튼을 숨기는 기능은 사용자 편의성과 일부 오류 방지에 도움이 될 수 있지만 보안 통제의 최종 근거가 되어서는 안 된다.
공격자는 브라우저에서 전송되는 HTTP 요청을 직접 구성하거나 변경할 수 있으므로, 중요한 보안 검증은 서버 측에서 수행해야 한다.
인젝션(Injection)은 외부 입력이 프로그램에서 단순한 데이터가 아니라 명령어나 질의문의 일부로 해석되어 의도하지 않은 동작을 유발하는 취약점이다.
대표적인 유형에는 SQL 인젝션, 운영체제 명령어 인젝션, LDAP 인젝션 및 서버 측 템플릿 인젝션 등이 있다.
인젝션을 방지하기 위해서는 데이터와 명령을 분리하고, 매개변수화된 인터페이스와 안전한 API를 사용해야 한다.
단순히 특정 문자나 문자열을 제거하는 방식만으로 모든 인젝션 취약점을 방지하기는 어렵다.
크로스 사이트 스크립팅(Cross-Site Scripting, XSS)은 웹 애플리케이션이 신뢰할 수 없는 데이터를 안전하지 않게 처리하여 브라우저에서 의도하지 않은 스크립트가 실행되는 취약점이다.
XSS는 반사형, 저장형, DOM 기반 유형 등으로 구분된다.
방어에는 출력 위치에 맞는 인코딩, 안전한 DOM API, HTML 정화 및 콘텐츠 보안 정책 등이 활용된다.
특히 HTML 본문과 HTML 속성, JavaScript 문자열, URL 등은 서로 다른 출력 문맥이므로 동일한 인코딩 방식을 무조건 적용해서는 안 된다.
접근통제 실패(Broken Access Control)는 사용자가 허용되지 않은 정보나 기능에 접근할 수 있는 취약점이다.
대표적인 사례에는 다른 사용자의 자료 조회, 일반 사용자의 관리자 기능 실행 및 객체 식별자 변조를 통한 비인가 접근 등이 있다.
접근통제는 화면이나 메뉴 단위뿐 아니라 서버의 개별 API와 데이터 객체 단위로 적용해야 한다.
OWASP Top 10:2025는 접근통제 실패를 A01 항목으로 분류하고 있다.[2]
인증 실패(Authentication Failures)는 사용자 신원 확인과 인증정보 처리에 결함이 발생하는 문제이다.
비밀번호 검증 오류, 취약한 계정 복구 절차, 인증토큰 검증 누락 및 다중요소인증 우회 등이 포함될 수 있다.
인증을 강화하더라도 인가 검증이 잘못되어 있다면 다른 사용자의 데이터에 접근하는 문제가 발생할 수 있으므로 인증과 인가는 구분하여 관리해야 한다.
서버 측 요청 위조(Server-Side Request Forgery, SSRF)는 웹 애플리케이션이 공격자가 의도한 네트워크 대상으로 요청을 전송하도록 유도하는 취약점이다.
SSRF는 외부 URL을 가져오는 기능이나 웹훅, 파일 변환 및 이미지 처리 서비스 등에서 발생할 수 있다.
서버가 내부망이나 클라우드 메타데이터 서비스에 접근할 수 있다면 SSRF의 영향이 확대될 수 있다.
방어에는 요청 대상 제한, 주소 검증, 네트워크 접근통제, 리다이렉션 제한 및 클라우드 자격증명 보호 등이 활용된다.
파일 업로드 기능은 악성 파일 저장, 파일 형식 검증 우회, 서버 측 코드 실행 및 파일 처리 라이브러리의 취약점 악용 등의 위험을 수반한다.
업로드 파일은 허용된 형식과 크기를 검증하고, 서버에서 실행되지 않는 위치에 저장하는 것이 바람직하다.
파일 확장자와 클라이언트가 제공하는 MIME 형식만을 신뢰해서는 안 된다.
보안 설정 오류(Security Misconfiguration)는 불필요한 기능이나 관리 인터페이스 노출, 기본 계정 사용, 과도한 권한, 잘못된 HTTP 헤더 및 공개 저장소 설정 등으로 발생할 수 있다.
애플리케이션 코드가 안전하더라도 인프라와 배포 설정이 잘못되어 있다면 보안사고가 발생할 수 있다.
OWASP Top 10은 웹 애플리케이션의 주요 보안 위험을 정리한 문서이다.
개발자와 보안 담당자가 중요한 위험 유형을 이해하고 개선 우선순위를 검토하는 데 활용한다.
OWASP Top 10은 웹 애플리케이션 보안에 관한 인식 제고 자료이며, 모든 취약점을 빠짐없이 점검하기 위한 상세 검증 기준은 아니다.
2025년판 OWASP Top 10의 주요 항목은 다음과 같다.[2]
| 번호 | 영문 명칭 | 주요 내용 |
|---|---|---|
| A01 | Broken Access Control | 접근통제 실패 |
| A02 | Security Misconfiguration | 보안 설정 오류 |
| A03 | Software Supply Chain Failures | 소프트웨어 공급망 보안 실패 |
| A04 | Cryptographic Failures | 암호화 관련 보안 실패 |
| A05 | Injection | 인젝션 |
| A06 | Insecure Design | 안전하지 않은 설계 |
| A07 | Authentication Failures | 인증 실패 |
| A08 | Software or Data Integrity Failures | 소프트웨어 또는 데이터 무결성 검증 실패 |
| A09 | Security Logging & Alerting Failures | 보안 로깅 및 경보 실패 |
| A10 | Mishandling of Exceptional Conditions | 예외 상황 처리 실패 |
2025년판에서는 소프트웨어 공급망 보안 실패와 예외 상황 처리 실패가 주요 위험 항목으로 포함되었다.
이는 웹 보안이 단순한 입력값 검증과 웹 서버 설정을 넘어 개발·배포 과정과 외부 의존성, 오류 처리 및 운영체계까지 확대되고 있음을 보여준다.
인증(Authentication)은 사용자가 주장하는 신원을 확인하는 과정이다.
일반적인 웹서비스에서는 비밀번호, 일회용 인증번호, 인증 앱, 보안키 및 패스키 등의 수단이 활용된다.
인증 수단의 선택은 서비스의 위험도와 사용자 편의성, 계정 탈취 가능성 등을 고려해야 한다.
다중요소인증(Multi-Factor Authentication, MFA)은 서로 다른 인증 요소를 둘 이상 조합하여 사용자를 확인하는 방식이다.
인증 요소는 일반적으로 지식 요소, 소유 요소 및 생체적 특성 등으로 구분한다.
다중요소인증은 비밀번호 유출에 따른 계정 탈취 위험을 줄일 수 있지만 모든 형태의 피싱이나 세션 탈취를 방지하는 것은 아니다.
FIDO2와 WebAuthn 기반 인증은 서비스 도메인과 인증 과정이 결합되는 특성을 이용하여 피싱 저항성을 높일 수 있다.
인가(Authorization)는 인증된 사용자가 특정 자원이나 기능에 접근할 권한이 있는지 판단하는 과정이다.
인가 검증은 사용자의 역할뿐 아니라 접근 대상 객체, 요청 행위 및 업무 상태를 고려해야 할 수 있다.
역할 기반 접근통제(RBAC), 속성 기반 접근통제(ABAC) 및 정책 기반 접근통제 등이 활용된다.
인가 검증은 서버 측에서 수행해야 하며, 요청에 포함된 사용자 식별자나 역할 값을 그대로 신뢰해서는 안 된다.
객체 수준 접근통제는 사용자가 특정 문서, 주문, 계좌, 파일 또는 기타 데이터 객체에 접근할 권한이 있는지 확인하는 것이다.
예를 들어 사용자가 자신의 주문내역을 조회할 수 있다고 해서 다른 사용자의 주문내역을 조회할 권한이 있는 것은 아니다.
객체 식별자가 UUID처럼 추측하기 어려운 값이더라도 서버 측 인가 검사를 생략해서는 안 된다.
HTTP는 기본적으로 개별 요청과 응답이 독립적인 프로토콜이다.
웹 애플리케이션은 사용자의 로그인 상태와 권한 등을 여러 요청에 걸쳐 유지하기 위해 세션 관리 기능을 사용한다.
세션 식별자나 인증토큰이 유출되면 공격자가 해당 사용자의 인증상태를 악용할 수 있으므로, 세션정보는 중요한 보안자산으로 취급해야 한다.
OWASP는 세션 식별자의 안전한 생성과 전달, 수명 관리 및 종료 처리 등을 세션 보안의 핵심 요소로 제시한다.[3]
웹서비스에서 세션 쿠키를 사용하는 경우 다음과 같은 보안 속성을 적용할 수 있다.
| 속성 | 주요 기능 |
|---|---|
| Secure | HTTPS 연결에서만 쿠키 전송 |
| HttpOnly | JavaScript에서 쿠키에 직접 접근하는 것을 제한 |
| SameSite | 교차 사이트 요청에서 쿠키 전송을 제한 |
| Path | 쿠키를 전송할 URL 경로 범위 지정 |
| Domain | 쿠키가 적용되는 도메인 범위 지정 |
| Max-Age / Expires | 쿠키의 유효기간 설정 |
Secure와 HttpOnly, SameSite는 서로 다른 위험을 완화하는 속성이다.
예를 들어 HttpOnly는 스크립트에서 쿠키 값을 직접 읽는 것을 제한하지만, XSS가 발생한 브라우저에서 인증된 요청이 실행되는 것까지 모두 차단하지는 못한다.
SameSite 역시 CSRF 위험을 완화하는 데 도움이 되지만 모든 환경에서 CSRF 토큰이나 서버 측 요청 검증을 대체할 수 있는 것은 아니다.[3]
세션은 로그인 이후 적절한 시점에 발급되고, 인증 상태가 변경되거나 위험한 이벤트가 발생했을 때 갱신 또는 종료될 수 있어야 한다.
로그아웃된 세션은 서버에서 더 이상 유효한 인증수단으로 인정되지 않아야 한다.
중요한 권한 변경이나 계정 복구, 비밀번호 변경 등의 상황에서는 세션 재발급이나 재인증을 고려할 수 있다.
HTTPS는 HTTP 통신을 TLS(Transport Layer Security)로 보호하는 방식이다.
TLS는 통신 상대방의 인증과 데이터의 기밀성·무결성을 제공한다.
HTTPS를 사용하면 네트워크 중간에서 HTTP 통신 내용을 쉽게 열람하거나 변조하는 위험을 줄일 수 있다.
그러나 HTTPS는 웹 애플리케이션 내부의 SQL 인젝션이나 XSS, 접근통제 오류를 직접 방지하지는 못한다.
또한 TLS 연결이 로드 밸런서나 리버스 프록시에서 종료되는 경우, 해당 지점과 백엔드 사이의 통신도 별도로 보호해야 할 수 있다.
TLS 서버 인증서는 접속 대상 서버의 신원을 확인하는 데 사용된다.
브라우저는 인증서의 유효기간과 도메인 일치 여부, 신뢰할 수 있는 인증기관에 의한 서명 등을 검증한다.
인증서 검증을 비활성화하면 공격자가 통신을 가로채거나 위조된 서버로 연결을 유도할 위험이 증가한다.
HTTP Strict Transport Security(HSTS)는 브라우저가 특정 사이트에 대해 HTTPS 연결을 사용하도록 지시하는 보안정책이다.
HSTS는 HTTP 연결로의 다운그레이드 위험을 줄이는 데 도움이 된다.
다만 HSTS가 최초 접속부터 항상 보호를 제공하는 것은 아니며, 사전 로드 목록(Preload List) 등의 적용 여부에 따라 보호 범위가 달라진다.
동일 출처 정책(Same-Origin Policy)은 서로 다른 출처의 웹 콘텐츠가 상대방의 데이터에 접근하는 것을 제한하는 브라우저 보안 원칙이다.
출처(Origin)는 일반적으로 스킴, 호스트 및 포트의 조합으로 정의된다.
동일 출처 정책은 악성 웹페이지가 다른 웹사이트의 민감한 응답 내용을 임의로 읽는 것을 제한하는 중요한 보호수단이다.
교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 서버가 특정 교차 출처 요청에 대해 브라우저의 응답 접근을 허용하도록 정책을 표현하는 기술이다.
CORS는 서버 측 인증이나 인가를 대체하는 보안기능이 아니다.
또한 브라우저가 CORS 정책에 따라 응답 접근을 제한하더라도 브라우저 이외의 클라이언트에서 API 요청 자체가 불가능해지는 것은 아니다.
따라서 CORS 설정과 별개로 서버 측 접근통제를 적용해야 한다.
콘텐츠 보안 정책(Content Security Policy, CSP)은 웹페이지에서 실행하거나 불러올 수 있는 스크립트와 스타일, 이미지 및 기타 리소스의 출처 등을 제한하는 보안정책이다.
CSP는 일부 XSS와 콘텐츠 삽입 공격의 영향을 줄이는 데 도움이 된다.
그러나 부적절하게 구성된 CSP는 충분한 보호를 제공하지 못할 수 있으며, CSP 적용만으로 XSS 취약점이 제거되는 것은 아니다.
서브리소스 무결성(Subresource Integrity, SRI)은 외부에서 불러오는 JavaScript나 CSS 등의 리소스가 예상한 내용과 일치하는지 확인하기 위한 기능이다.
브라우저는 지정된 해시값과 실제 리소스의 해시값을 비교하여 무결성을 검증할 수 있다.
SRI는 외부 정적 리소스의 변조 위험을 줄이는 데 유용하지만 모든 외부 서비스 연동이나 소프트웨어 공급망 위험을 해결하지는 못한다.
API(Application Programming Interface)는 애플리케이션과 외부 시스템 사이에서 기능과 데이터를 교환하기 위한 인터페이스이다.
웹 API는 브라우저뿐 아니라 모바일 애플리케이션, 외부 서버 및 자동화 프로그램에서도 호출할 수 있다.
따라서 API 보안은 사용자 화면의 제약에 의존하지 않고 서버 측 인증·인가와 입력 검증을 중심으로 설계해야 한다.
OWASP는 API에 특화된 주요 보안 위험을 정리한 API Security Top 10을 제공한다.
2023년판에는 객체 수준 인가 실패, 인증 실패, 객체 속성 수준 인가 실패, 무제한 자원 소비 및 민감한 업무 흐름의 무제한 접근 등이 포함된다.[4]
API 보안에서는 특히 객체별 권한 검증과 요청량 관리, 외부 API 응답의 신뢰성 검증이 중요하다.
API 키는 API 호출 주체를 식별하거나 접근을 제한하기 위해 사용되는 인증정보이다.
API 키가 유출되면 공격자가 해당 키의 권한 범위에서 API를 호출할 수 있다.
따라서 API 키는 소스코드 저장소나 공개된 클라이언트 코드에 노출되지 않도록 관리해야 한다.
서버 간 통신에서는 비밀정보 관리시스템과 권한 제한, 키 교체 및 호출 기록 분석 등을 활용할 수 있다.
요청량 제한(Rate Limiting)은 일정 시간 동안 허용되는 요청 수나 자원 사용량을 제한하는 기술이다.
무차별 대입 공격, 대량 정보 수집, 자원 고갈 및 자동화된 업무 악용 등을 완화하는 데 활용된다.
그러나 단순한 IP 주소별 요청량 제한만으로 분산된 공격이나 계정별 악용을 모두 차단하기는 어렵다.
웹 서버 하드닝(Hardening)은 불필요한 기능과 서비스, 권한 및 설정을 제거하거나 제한하여 공격면을 줄이는 활동이다.
사용하지 않는 모듈과 관리 페이지를 비활성화하고, 디렉터리 목록 노출을 제한하며, 보안 패치를 적용하는 등의 조치가 포함된다.
웹 서버 프로세스에는 필요한 최소한의 파일 및 시스템 접근권한을 부여해야 한다.
웹 애플리케이션 방화벽(Web Application Firewall, WAF)은 HTTP 및 HTTPS 요청을 분석하여 웹 애플리케이션을 대상으로 하는 공격을 탐지하거나 차단하는 보안기술이다.
WAF는 SQL 인젝션과 XSS 등 알려진 공격 패턴을 탐지하고, 요청량 제한과 IP 기반 접근통제 등을 수행할 수 있다.
그러나 WAF는 서버 측 인가 오류와 복잡한 비즈니스 로직 취약점을 모두 해결하지 못한다.
따라서 WAF는 안전한 애플리케이션 개발과 보안 설정을 보완하는 수단으로 사용해야 한다.
분산 서비스 거부 공격(Distributed Denial of Service, DDoS)은 다수의 공격원에서 대량의 트래픽이나 요청을 발생시켜 서비스의 가용성을 저해하는 공격이다.
웹서비스는 CDN과 트래픽 분산, 요청량 제한, 네트워크 기반 DDoS 방어 및 애플리케이션 계층 보호 등을 조합하여 대응할 수 있다.
대역폭을 소진시키는 공격과 애플리케이션의 CPU·메모리·데이터베이스 자원을 고갈시키는 공격은 특성이 다르므로 각각에 적합한 보호수단이 필요하다.
CDN이나 WAF를 통해 외부 트래픽을 처리하는 서비스는 원본 서버(Origin Server)에 직접 접근할 수 있는 경로를 제한하는 것이 중요하다.
원본 서버가 인터넷에 직접 노출되어 있다면 공격자가 CDN이나 WAF를 우회하여 원본 서버로 요청을 전송할 수 있다.
원본 접근 제한에는 네트워크 방화벽, 허용된 프록시 주소 제한, 상호 TLS 인증 및 사설 네트워크 연결 등이 활용될 수 있다.
웹서비스는 개인정보와 인증정보, 금융정보 등 민감한 데이터를 저장할 때 적절한 암호화와 접근통제를 적용해야 한다.
암호화 키는 보호 대상 데이터와 분리하여 관리하는 것이 바람직하다.
암호화가 적용되어 있더라도 애플리케이션이 복호화 권한을 과도하게 보유하거나 키가 유출되면 보호효과가 제한될 수 있다.
사용자 비밀번호는 복호화 가능한 일반적인 암호화 방식이나 단순 해시값으로 저장해서는 안 된다.
비밀번호 저장에는 Argon2id, scrypt, bcrypt 또는 적절하게 구성된 PBKDF2 등 비밀번호 해싱에 적합한 알고리즘을 사용할 수 있다.
각 비밀번호에는 고유한 솔트(Salt)를 적용하고, 알고리즘의 비용 매개변수를 적절히 설정해야 한다.
데이터베이스 비밀번호와 API 키, 암호화 키, 인증서 개인키 등은 별도의 비밀정보 관리체계를 통해 보호할 수 있다.
이러한 정보가 소스코드 저장소나 컨테이너 이미지, 로그 또는 클라이언트 코드에 포함되지 않도록 주의해야 한다.
비밀정보는 접근권한을 최소화하고 필요에 따라 교체·폐기할 수 있어야 한다.
소프트웨어 공급망 보안은 애플리케이션의 개발과 빌드, 배포 및 운영에 사용되는 외부 구성요소와 도구, 서비스의 위험을 관리하는 활동이다.
현대적인 웹서비스는 오픈소스 라이브러리와 패키지 관리자, CI/CD 도구 및 컨테이너 이미지 등에 의존하는 경우가 많다.
외부 패키지에 취약점이나 악성코드가 포함되면 애플리케이션 자체의 소스코드에 직접적인 결함이 없어도 침해사고가 발생할 수 있다.
소프트웨어 구성명세서(Software Bill of Materials, SBOM)는 소프트웨어를 구성하는 라이브러리와 패키지 등의 정보를 구조화하여 기록한 문서이다.
대표적인 형식에는 SPDX와 CycloneDX 등이 있다.
SBOM은 소프트웨어의 구성요소와 의존관계를 파악하고 알려진 취약점의 영향을 분석하는 데 도움이 된다.
그러나 SBOM을 생성했다는 사실만으로 해당 소프트웨어가 안전하다는 것을 보장하지는 않는다.
외부 라이브러리와 패키지는 버전과 지원 종료 여부, 알려진 취약점 및 배포 출처 등을 관리해야 한다.
의존성 업데이트는 취약점을 수정하는 데 중요하지만, 업데이트 과정에서 호환성 문제나 새로운 위험이 발생할 수도 있다.
따라서 업데이트 검증과 테스트, 배포 승인 및 롤백 절차가 필요하다.
CI/CD 파이프라인은 소스코드와 빌드 결과물, 배포 권한에 접근할 수 있으므로 중요한 보호 대상이다.
빌드 환경의 접근통제와 비밀정보 보호, 산출물 서명 및 배포 승인 절차 등을 적용할 수 있다.
또한 운영 환경에 배포되는 소프트웨어가 승인된 소스코드와 빌드 과정을 통해 생성되었는지 확인하는 무결성 검증이 중요하다.
보안 개발 생명주기(Secure Software Development Life Cycle, SSDLC)는 소프트웨어의 기획부터 설계, 개발, 테스트, 배포 및 운영에 이르기까지 보안 활동을 통합하는 방식이다.
개발 완료 후 취약점을 점검하는 것만으로는 설계 단계에서 발생한 보안 문제를 충분히 해결하기 어려울 수 있다.
따라서 보안 요구사항과 위협 모델링, 코드 검토 및 보안 테스트를 개발 과정에 포함하는 것이 중요하다.
DevSecOps는 개발(Development), 보안(Security), 운영(Operations)을 통합하여 소프트웨어의 개발·배포 과정에서 보안 활동을 지속적으로 수행하는 접근방식이다.
자동화된 코드 분석과 의존성 점검, 비밀정보 탐지, 컨테이너 이미지 검사 및 배포 정책 검증 등을 CI/CD 파이프라인에 통합할 수 있다.
DevSecOps의 핵심은 특정 보안 도구를 설치하는 것만이 아니라 개발자와 보안 담당자, 운영 담당자 사이의 책임과 협업체계를 구축하는 데 있다.
OWASP ASVS(Application Security Verification Standard)는 웹 애플리케이션과 웹서비스의 보안 요구사항을 검증하기 위한 기준이다.
2025년 5월 30일 발표된 ASVS 5.0.0은 웹 애플리케이션의 기술적 보안 통제를 설계·개발·검증하는 데 활용할 수 있는 요구사항을 제공한다.[1]
ASVS는 보안 점검 항목을 체계적으로 구성하고 개발 요구사항이나 조달 계약의 보안 기준으로 활용하는 데 적합하다.
OWASP Top 10이 주요 위험을 개괄적으로 설명하는 자료라면, ASVS는 보다 구체적인 보안 검증 요구사항을 제공한다는 차이가 있다.
OWASP Web Security Testing Guide(WSTG)는 웹 애플리케이션 보안 테스트를 위한 방법론과 점검 절차를 제공한다.
정보 수집과 설정 검토, 인증, 인가, 세션 관리, 입력 검증, 암호화 및 업무 로직 등의 영역을 다룬다.[7]
WSTG는 보안 테스트 수행에 유용하지만, 특정 서비스에 적용할 점검 범위는 실제 시스템 구조와 위험도에 따라 결정해야 한다.
정적 애플리케이션 보안 테스트(Static Application Security Testing, SAST)는 프로그램을 실행하지 않고 소스코드나 바이너리를 분석하여 취약점 가능성을 탐지하는 방식이다.
SQL 인젝션과 잘못된 데이터 흐름, 취약한 함수 사용 등 다양한 문제를 발견하는 데 활용할 수 있다.
그러나 실행 환경의 설정이나 실제 업무 흐름에 따라 발생하는 취약점을 모두 발견하지는 못할 수 있다.
동적 애플리케이션 보안 테스트(Dynamic Application Security Testing, DAST)는 실행 중인 웹 애플리케이션에 요청을 전송하고 응답을 분석하여 취약점을 탐지하는 방식이다.
실제 서비스 인터페이스를 통해 점검할 수 있다는 장점이 있지만, 코드 내부의 모든 경로와 조건을 확인할 수 있는 것은 아니다.
또한 자동화된 점검은 서비스에 부하를 주거나 데이터를 변경할 가능성이 있으므로 적절한 점검 범위와 환경을 설정해야 한다.
소프트웨어 구성 분석(Software Composition Analysis, SCA)은 애플리케이션에서 사용하는 외부 라이브러리와 패키지의 취약점, 버전 및 라이선스 등을 분석하는 활동이다.
SCA는 알려진 취약점을 가진 의존성을 식별하는 데 유용하지만, 자체 개발한 코드의 모든 보안 결함을 탐지하는 것은 아니다.
모의해킹(Penetration Testing)은 실제 공격자의 관점에서 취약점을 발견하고 악용 가능성과 보안 영향을 검증하는 활동이다.
웹 모의해킹은 인증과 접근통제, 입력값 처리, 업무 로직 및 외부 연동 기능 등을 대상으로 수행할 수 있다.
자동화된 스캐너만으로 발견하기 어려운 비즈니스 로직 취약점과 복합적인 공격 경로를 분석하는 데 유용하다.
모의해킹은 사전에 승인된 대상과 기간, 허용된 행위의 범위 내에서 수행해야 한다.
웹서비스 운영자는 사용하는 소프트웨어와 라이브러리, 서버 및 클라우드 서비스의 취약점 정보를 지속적으로 확인해야 한다.
취약점의 심각도뿐 아니라 실제 공격 가능성, 인터넷 노출 여부, 서비스 중요도 및 적용 가능한 완화조치 등을 고려하여 대응 우선순위를 정해야 한다.
보안 패치는 운영 안정성을 검토한 후 신속하게 적용하는 것이 바람직하다.
웹서비스에서는 인증 실패, 권한 오류, 관리자 기능 사용, 중요한 데이터 변경 및 비정상적인 API 호출 등을 기록할 수 있다.
보안 로그는 침해사고의 탐지와 원인 분석, 사후 대응에 활용된다.
그러나 로그에 비밀번호나 인증토큰, 불필요한 개인정보가 기록되면 로그 자체가 새로운 정보유출 위험이 될 수 있다.
따라서 로그의 수집 범위와 보존기간, 접근권한 및 무결성 보호를 함께 관리해야 한다.
웹서비스는 정상적인 요청과 비정상적인 요청의 특성을 분석하여 공격 징후를 탐지할 수 있다.
대표적인 탐지 대상에는 반복적인 로그인 실패, 대량 데이터 조회, 비정상적인 API 호출량 및 관리자 기능에 대한 무단 접근 시도 등이 있다.
이상행위 탐지는 규칙 기반 탐지와 통계적 분석, 행동 분석 등을 조합하여 수행할 수 있다.
웹 보안 사고가 발생하면 사고의 범위와 영향을 확인하고, 공격 경로를 차단하며, 증거를 보존해야 한다.
침해된 계정이나 인증정보를 교체하고 취약점을 수정한 뒤 서비스의 안전성을 검증해야 한다.
개인정보 유출이나 관련 법령에 따른 신고·통지 의무가 발생하는 경우에는 법적 요건과 기한에 따라 대응해야 한다.
웹서비스의 데이터와 설정은 장애나 침해사고에 대비하여 적절하게 백업해야 한다.
백업은 운영 시스템과 분리하여 보호하고, 접근권한과 무결성을 관리해야 한다.
또한 백업을 보유하는 것만으로 복구 가능성이 보장되는 것은 아니므로 정기적인 복구 테스트가 필요하다.
클라우드 환경에서는 클라우드 서비스 제공자와 고객이 보안 책임을 나누어 부담한다.
책임 범위는 IaaS, PaaS, SaaS 등 서비스 모델과 개별 서비스의 특성에 따라 달라진다.
일반적으로 고객은 애플리케이션의 보안과 사용자 권한, 데이터 보호 및 서비스 설정 등에 대한 책임을 부담한다.
관리형 서비스를 사용하더라도 애플리케이션의 인증·인가 오류나 잘못된 공개 설정이 자동으로 해결되는 것은 아니다.
컨테이너 기반 웹서비스에서는 컨테이너 이미지의 취약점과 실행 권한, 비밀정보 관리 및 네트워크 정책 등을 고려해야 한다.
쿠버네티스 환경에서는 서비스 계정 권한, 네트워크 정책, 인그레스 설정 및 컨테이너 실행 보안 등이 중요하다.
컨테이너를 사용한다는 사실만으로 애플리케이션이 안전하게 격리되는 것은 아니며, 호스트와 런타임 및 오케스트레이션 환경의 보안도 필요하다.
서버리스 웹서비스에서는 클라우드 사업자가 서버 인프라의 상당 부분을 관리하지만 애플리케이션 코드와 권한 설정, 외부 연동 및 데이터 보호는 여전히 중요한 보안 관리대상이다.
특히 서버리스 함수에 과도한 IAM 권한이 부여되면 애플리케이션 취약점이 악용되었을 때 다른 클라우드 자원으로 피해가 확대될 수 있다.
AI 기능을 제공하는 웹서비스는 기존 웹 애플리케이션의 보안 요구사항에 더하여 AI 모델과 외부 데이터, 도구 호출 및 에이전트 실행에 관한 위험을 고려해야 한다.
사용자 입력이나 검색 결과, 외부 문서가 AI 모델의 처리 과정에 포함되는 경우 해당 데이터의 신뢰 수준을 구분해야 한다.
프롬프트 인젝션(Prompt Injection)은 공격자가 AI 모델에 전달되는 입력이나 외부 콘텐츠에 지시문을 삽입하여 의도하지 않은 동작을 유도하는 공격이다.
AI 모델이 웹 검색 결과나 문서 내용을 처리하는 과정에서 외부 콘텐츠의 지시를 높은 신뢰 수준의 명령처럼 취급하면 문제가 발생할 수 있다.
프롬프트 인젝션은 SQL 인젝션과 명칭이 유사하지만 발생 원리와 방어 방식이 동일하지는 않다.
AI 에이전트가 데이터베이스 조회나 파일 접근, 외부 API 호출 등의 작업을 수행할 수 있다면 모델이 생성한 도구 호출 요청에 대해서도 서버 측 권한 검증을 적용해야 한다.
AI 모델의 판단만으로 중요한 거래나 데이터 변경을 승인하는 구조는 위험할 수 있다.
민감한 작업에는 최소 권한과 실행 범위 제한, 사용자 확인 및 감사 로그 등을 적용할 수 있다.
웹서비스는 새로운 기능과 외부 라이브러리, 운영환경의 변경에 따라 공격면이 계속 변화한다.
따라서 특정 시점에 취약점 진단을 통과했거나 보안 인증을 취득했다는 사실만으로 이후에도 취약점이 발생하지 않는다고 보장할 수 없다.
보안은 일회성 점검이 아니라 지속적인 위험 관리 활동으로 이해해야 한다.
보안 통제를 강화하면 사용자의 편의성이나 서비스 성능에 영향을 줄 수 있다.
예를 들어 지나치게 엄격한 요청량 제한은 정상적인 사용자의 접근을 방해할 수 있고, 과도한 재인증은 서비스 이용을 어렵게 만들 수 있다.
따라서 서비스의 위험도와 사용환경을 고려하여 적절한 수준의 보안 통제를 설계해야 한다.
자동화된 보안 도구는 알려진 취약점 패턴과 설정 오류를 효율적으로 탐지할 수 있다.
그러나 복잡한 업무 로직과 조직별 권한 구조, 여러 취약점의 연계 가능성을 모두 판단하기는 어렵다.
또한 자동화 도구의 탐지 결과에는 오탐과 미탐이 발생할 수 있으므로 검증과 위험도 평가가 필요하다.
현대적인 웹서비스는 개발팀과 인프라 운영팀, 보안팀 및 외부 서비스 제공자 등이 함께 운영하는 경우가 많다.
보안 책임이 명확하지 않으면 취약점 수정과 권한 관리, 사고 대응 과정에서 공백이 발생할 수 있다.
따라서 조직은 보안 요구사항과 책임 주체, 승인 절차 및 사고 대응체계를 명확하게 정의해야 한다.
웹 보안은 인터넷 기반 서비스의 신뢰성과 안정성을 확보하기 위한 핵심 분야이다.
웹서비스는 개인정보와 금융정보, 업무자료 및 인증정보를 처리하므로 보안 취약점이 악용되면 정보유출과 데이터 변조, 서비스 중단 및 금전적 피해로 이어질 수 있다.
웹 보안의 효과적인 구현을 위해서는 안전한 설계와 시큐어 코딩, 인증·인가, 통신 암호화, 웹 서버 하드닝, 공급망 관리 및 지속적인 보안 점검을 종합적으로 수행해야 한다.
특히 API와 클라우드, AI 기능이 웹서비스에 통합되면서 개별 웹 서버의 보안뿐 아니라 구성요소 사이의 신뢰 경계와 권한, 데이터 흐름을 보호하는 것이 중요해지고 있다.
웹 보안은 특정 보안제품을 설치하는 활동에 그치지 않으며, 개발과 운영 전 과정에서 위험을 식별하고 관리하는 지속적인 보안 활동으로 평가된다.
- ↑ 1.0 1.1 OWASP, 「Application Security Verification Standard 5.0.0」, https://asvs.owasp.org/, 2025-05-30 발표.
- ↑ 2.0 2.1 OWASP, 「OWASP Top 10:2025」, https://top10.owasp.org/2025/, 확인일: 2026-11-14.
- ↑ 3.0 3.1 OWASP, 「Session Management Cheat Sheet」, https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html, 확인일: 2026-11-14.
- ↑ OWASP, 「OWASP API Security Top 10 – 2023」, https://api-security.owasp.org/editions/2023/en/0x00-header/, 2023년 발표.
- ↑ NIST, 「SP 800-218: Secure Software Development Framework (SSDF) Version 1.1」, https://csrc.nist.gov/pubs/sp/800/218/final, 2022-02 발표.
- ↑ NIST, 「Secure Software Development Framework (SSDF) Version 1.2 is Available for Public Comment」, https://content.govdelivery.com/accounts/USNIST/bulletins/3fdbb23, 2025-12-17.
- ↑ OWASP, 「Web Security Testing Guide」, https://owasp.org/www-project-web-security-testing-guide/, 확인일: 2026-11-14.