📑 목차
- 서론: 왜 OWASP Top 10에 주목해야 하는가?
- OWASP Top 10, 웹 보안의 핵심 지표
- OWASP Top 10의 중요성
- 주요 취약점 분석 및 방어 전략 (실전편)
- 1. A01:2021 – Injection (인젝션)
- 2. A02:2021 – Broken Authentication (취약한 인증)
- 3. A03:2021 – Injection (크로스 사이트 스크립팅, XSS)
- 4. A05:2021 – Security Misconfiguration (보안 설정 오류)
- 실무에서 마주한 보안 위협과 대응 경험
- 보안 취약점 점검 도구 활용 팁
- 1. SAST (Static Application Security Testing)
- 2. DAST (Dynamic Application Security Testing)
- 3. IAST (Interactive Application Security Testing)
- 지속적인 보안 강화의 중요성
- 마무리: 안전한 웹 서비스를 위한 우리의 노력
Image by fancycrave1 on Pixabay
서론: 왜 OWASP Top 10에 주목해야 하는가?
웹 애플리케이션 개발자라면 누구나 한 번쯤은 보안 사고에 대한 두려움을 느껴보셨을 겁니다. 밤샘 작업 끝에 배포한 서비스가 단 한 번의 취약점으로 인해 무너진다면? 고객 정보 유출로 이어져 기업 신뢰도 하락은 물론, 법적 책임까지 질 수 있는 상황은 상상만 해도 끔찍합니다. 실제로 많은 서비스들이 개발 과정에서 간과된 보안 취약점으로 인해 심각한 피해를 겪습니다.
저 역시 처음에는 기능 구현에만 급급했던 시절이 있었습니다. "일단 동작하게 만들고, 나중에 보안을 신경 쓰자"는 안일한 생각이었죠. 하지만 작은 프로젝트에서 SQL Injection 취약점을 발견하고 식은땀을 흘렸던 경험, 그리고 실제 서비스에서 XSS 공격으로 사용자 세션 탈취 시도가 있었던 것을 막아내면서 보안의 중요성을 뼈저리게 느꼈습니다. 이때부터 OWASP Top 10은 저에게 단순한 체크리스트가 아니라, 안전한 웹 서비스를 만들기 위한 실질적인 가이드라인이 되었습니다.
이 글에서는 OWASP Top 10을 기반으로 웹 애플리케이션의 주요 보안 취약점을 분석하고, 실무에서 직접 적용해 본 방어 전략과 구체적인 예시를 공유하고자 합니다. 단순히 이론적인 내용을 넘어, "내가 직접 써보니" 혹은 "실제로 적용해 본 결과" 어떤 효과가 있었는지 경험담을 녹여내려 합니다. 여러분의 웹 서비스가 더욱 안전해지는 데 작은 도움이 되기를 바랍니다.
OWASP Top 10, 웹 보안의 핵심 지표
OWASP (Open Web Application Security Project)는 웹 애플리케이션 보안 분야에서 가장 공신력 있는 비영리 단체입니다. 이들이 주기적으로 발표하는 OWASP Top 10은 웹 애플리케이션에서 가장 빈번하게 발생하고, 파급력이 큰 10가지 취약점을 선정하여 개발자와 보안 전문가들에게 경각심을 일깨우고 대응을 독려하는 가이드라인입니다. 이 목록은 웹 환경의 변화를 반영하여 꾸준히 재평가되고 업데이트됩니다.
OWASP Top 10은 단순히 취약점 목록을 나열하는 것을 넘어, 각 취약점의 위험도, 발견 용이성, 악용 가능성 등을 종합적으로 고려하여 우선순위를 제시합니다. 덕분에 제한된 자원 속에서 가장 효과적인 보안 투자를 할 수 있도록 돕는 나침반 역할을 합니다. 예를 들어, 제가 초기 프로젝트에서 보안 컨설팅을 진행할 때, 이 목록을 기반으로 진단 범위를 설정하고 개발팀과 소통하면서 "가장 먼저 해결해야 할 문제"를 명확히 할 수 있었습니다.
OWASP Top 10의 중요성
- 위험 관리의 기준: 가장 위험하고 흔한 취약점에 집중하여 보안 리스크를 효과적으로 관리할 수 있습니다.
- 보안 교육의 기초: 개발자들이 웹 보안의 기본 개념과 주요 위협을 이해하는 데 큰 도움이 됩니다.
- 보안 감사 및 점검의 지표: 서비스 출시 전 보안 점검이나 정기 감사 시, 이 목록을 기준으로 취약점을 찾아내고 개선하는 데 활용됩니다.
- 보안 커뮤니티의 공통 언어: 전 세계 보안 전문가들이 동일한 기준으로 취약점을 논의하고 해결책을 공유하는 데 기반이 됩니다.
주요 취약점 분석 및 방어 전략 (실전편)
이제 OWASP Top 10에 포함된 주요 취약점들을 몇 가지 선정하여, 실제로 어떻게 공격이 이루어지고 또 어떻게 방어해야 하는지 구체적인 경험을 바탕으로 설명해 드립니다.
1. A01:2021 – Injection (인젝션)
인젝션은 공격자가 웹 애플리케이션의 입력값을 조작하여 의도치 않은 명령이나 쿼리를 실행시키는 취약점입니다. 가장 대표적인 것이 SQL Injection이며, 저 역시 입사 초기 게시판에서 이 취약점을 발견하고 아찔했던 기억이 있습니다. 당시에는 사용자 입력값을 그대로 SQL 쿼리에 삽입하는 코드가 비일비재했습니다.
공격 시나리오:
로그인 폼에서 사용자 ID 입력란에 ' OR '1'='1 과 같은 값을 넣으면, 백엔드에서 다음과 같은 쿼리가 생성될 수 있습니다.
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '입력된 비밀번호';'1'='1'은 항상 참이므로, 비밀번호가 틀려도 로그인에 성공하거나, 더 나아가 데이터베이스의 모든 정보를 탈취할 수도 있습니다.
방어 전략 (실제 적용 경험):
- Prepared Statement (매개변수화된 쿼리) 사용: 이것은 SQL Injection을 막는 가장 기본적인이자 효과적인 방법입니다. 제가 직접 DB 연동 코드를 개선할 때 가장 먼저 적용했던 부분이기도 합니다. 사용자 입력값을 데이터와 쿼리 구조를 분리하여 처리하므로, 입력값이 아무리 악의적이어도 쿼리 구조를 변경할 수 없습니다.
// Java 예시 (PreparedStatement 사용)
String query = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement pstmt = connection.prepareStatement(query);
pstmt.setString(1, usernameInput);
pstmt.setString(2, passwordInput);
ResultSet rs = pstmt.executeQuery();- 입력값 검증 (Input Validation): 모든 사용자 입력값은 서버단에서 엄격하게 검증해야 합니다. 허용된 문자열, 길이, 형식 등을 화이트리스트 방식으로 정의하고, 이를 벗어나는 입력은 거부합니다. 예를 들어, ID는 영문 소문자와 숫자만 허용하고, 최대 길이를 제한하는 식입니다.
- 에러 메시지 최소화: 공격자에게 유용한 정보(예: SQL 에러 메시지)를 노출하지 않도록 일반적인 에러 메시지를 반환하도록 설정해야 합니다.
2. A02:2021 – Broken Authentication (취약한 인증)
취약한 인증은 인증 또는 세션 관리 기능이 제대로 구현되지 않아 공격자가 사용자 계정을 탈취하거나 권한을 상승시키는 취약점입니다. 실제로 개발 초기 단계에서 가장 흔하게 놓치는 부분 중 하나가 세션 관리입니다. 토큰 유효기간을 너무 길게 설정하거나, HTTP Only 플래그를 누락하는 등의 실수를 자주 목격했습니다.
공격 시나리오:
- 무차별 대입 공격 (Brute-force): 짧고 예측 가능한 비밀번호를 사용하는 계정에 대해 반복적으로 로그인 시도를 하여 비밀번호를 알아냅니다.
- 세션 탈취: XSS 공격 등을 통해 세션 ID를 탈취한 후, 해당 ID로 로그인하여 사용자 행세를 합니다.
- 취약한 비밀번호 복구 로직: "비밀번호 찾기" 기능이 제대로 구현되지 않아 공격자가 쉽게 비밀번호를 재설정할 수 있게 됩니다.
방어 전략 (실제 적용 경험):
- 강력한 비밀번호 정책: 최소 길이, 대소문자, 숫자, 특수문자 조합 등 복잡도 요구사항을 적용하고, 주기적인 비밀번호 변경을 권장합니다. 사용자에게도 강력한 비밀번호의 중요성을 교육해야 합니다.
- 다단계 인증 (MFA): 로그인 시 비밀번호 외에 추가적인 인증 수단(SMS 인증, OTP 등)을 요구하여 보안을 강화합니다. 실제로 고객사 서비스에 OTP 인증을 도입한 후 무차별 대입 공격 시도가 현저히 줄어든 것을 확인할 수 있었습니다.
- 세션 관리 강화:
- 세션 ID는 예측 불가능하게 생성하고, 충분히 긴 무작위 문자열을 사용합니다.
- 세션 ID는 HTTP Only 및 Secure 플래그를 설정한 쿠키에 저장하여 XSS 공격으로부터 보호합니다.
- 로그아웃 시에는 반드시 서버에서 세션을 무효화해야 합니다.
- 일정 시간 동안 활동이 없으면 세션을 자동으로 만료시킵니다.
- 로그인 시도 제한: 특정 IP에서 짧은 시간 내에 로그인 실패 횟수가 일정 기준을 초과하면 해당 IP를 일시적으로 차단하거나 CAPTCHA를 요구합니다.
- 안전한 비밀번호 저장: 비밀번호는 단방향 해시 함수 (예: bcrypt, scrypt)와 솔트(Salt)를 사용하여 저장해야 합니다. 절대 평문으로 저장해서는 안 됩니다.
3. A03:2021 – Injection (크로스 사이트 스크립팅, XSS)
XSS는 웹 애플리케이션이 사용자로부터 입력받은 값을 검증 없이 웹 페이지에 포함할 때 발생합니다. 공격자는 악성 스크립트를 주입하여 다른 사용자들의 브라우저에서 실행되도록 만듭니다. 제가 개발했던 커뮤니티 게시판에서 저장형 XSS 취약점이 발견되어, 특정 게시글을 열람한 사용자들의 쿠키가 공격자에게 전송될 뻔했던 경험은 잊을 수 없습니다.
XSS 유형 및 공격 시나리오:
| 유형 | 설명 | 공격 시나리오 |
|---|---|---|
| 저장형 (Stored) XSS | 악성 스크립트가 서버에 저장되었다가 사용자에게 서비스될 때 실행 | 게시판 댓글에 <script>alert(document.cookie)</script> 삽입 → 다른 사용자가 댓글 열람 시 스크립트 실행 |
| 반사형 (Reflected) XSS | 악성 스크립트가 URL 파라미터를 통해 전달되어 서버에 반영 없이 즉시 사용자에게 반사되어 실행 | 공격자가 http://example.com/search?query=<script>alert(1)</script> 링크를 피해자에게 전송 → 피해자가 클릭 시 스크립트 실행 |
| DOM 기반 (DOM-based) XSS | 클라이언트 측 스크립트가 DOM 환경을 조작하여 악성 스크립트 실행 | URL 해시값(# 뒤)을 JavaScript가 파싱하여 페이지에 반영할 때 발생하는 경우가 많음 |
방어 전략 (실제 적용 경험):
- 출력 인코딩 (Output Encoding): 사용자 입력값이 HTML, JavaScript 등 특정 컨텍스트에 출력될 때, 특수 문자를 해당 컨텍스트에서 의미 없는 문자열로 변환(인코딩)해야 합니다. HTML 출력 시에는
<를<로,>를>로,&를&등으로 변환합니다. 모든 웹 프레임워크에는 이를 위한 유틸리티 함수가 내장되어 있습니다. 저는 주로 Thymeleaf나 JSP의 JSTL 같은 템플릿 엔진의 자동 이스케이프 기능을 적극 활용했습니다.
<!-- HTML 컨텍스트에서 출력 시 -->
<div>[[${user_input}]]</div> <!-- Thymeleaf 예시: 자동 HTML 인코딩 -->
// JavaScript 컨텍스트에서 출력 시 (주의 필요)
// var data = '<%- user_input %>'; // EJS 템플릿 예시
// JSON.stringify()를 사용하여 안전하게 데이터를 JavaScript로 전달하는 것이 더 안전합니다.
var data = JSON.parse('<%= user_input_json_encoded %>');- 콘텐츠 보안 정책 (Content Security Policy, CSP): 웹 서버에서 HTTP 응답 헤더에 CSP 정책을 추가하여, 브라우저가 어떤 출처의 스크립트, 스타일시트, 이미지 등을 로드하고 실행할 수 있는지 명시적으로 지정합니다. 이를 통해 예상치 못한 스크립트 실행을 차단할 수 있습니다.
script-src 'self' https://trusted.cdn.com;와 같이 설정하여 특정 도메인에서만 스크립트를 로드하도록 제한하는 방식입니다. 초기에는 복잡하게 느껴졌지만, 한 번 설정하고 나면 강력한 방어막이 됩니다. - 입력값 검증 및 필터링: XSS 공격에 사용될 수 있는 스크립트 태그(
<script>), 이벤트 핸들러(onmouseover등)를 블랙리스트 방식으로 필터링하는 것은 완벽하지 않으므로, 화이트리스트 방식으로 허용 가능한 태그와 속성만 허용하는 것이 더 안전합니다. 하지만 이 역시 복잡하며, 출력 인코딩이 더 근본적인 해결책입니다.
4. A05:2021 – Security Misconfiguration (보안 설정 오류)
보안 설정 오류는 웹 서버, 애플리케이션 서버, 데이터베이스, 프레임워크 등 모든 계층에서 발생할 수 있는 취약점입니다. 기본 보안 설정을 변경하지 않거나, 불필요한 기능 활성화, 민감한 정보 노출 등이 여기에 해당합니다. 저는 한 번은 운영 서버에서 개발용 디버깅 페이지가 그대로 노출되어 시스템 정보가 유출될 뻔한 아찔한 상황을 겪은 적이 있습니다.
공격 시나리오:
- 기본 계정 및 비밀번호 사용: 데이터베이스나 관리자 페이지에 기본 계정(admin/admin)이 그대로 남아있는 경우.
- 불필요한 서비스 활성화: 운영 환경에 디버깅 모드, 불필요한 포트, 관리자 인터페이스 등이 활성화된 경우.
- 디렉터리 리스팅: 웹 서버 설정 오류로 특정 디렉터리의 파일 목록이 노출되어 민감한 파일(설정 파일 등)이 유출되는 경우.
- 에러 메시지를 통한 정보 노출: 상세한 에러 메시지가 스택 트레이스 등 내부 시스템 정보를 노출하는 경우.
방어 전략 (실제 적용 경험):
- 보안 강화된 기본 설정 (Secure Default): 모든 시스템, 프레임워크, 라이브러리는 설치 후 기본 설정값을 변경하고, 불필요한 기능은 비활성화합니다. 특히, 관리자 계정의 비밀번호는 강력하게 설정하고 변경해야 합니다.
- 최소 권한 원칙 (Principle of Least Privilege): 각 서비스, 사용자, 프로세스에는 필요한 최소한의 권한만 부여합니다. 예를 들어, 데이터베이스 계정은 해당 서비스에 필요한 테이블에 대한 읽기/쓰기 권한만 가지도록 설정합니다.
- 환경 분리 및 설정 관리: 개발, 스테이징, 운영 환경을 명확히 분리하고, 각 환경에 맞는 보안 설정을 적용합니다. 민감한 설정 정보(API 키, DB 접속 정보)는 환경 변수나 비밀 관리 도구(Vault)를 사용하여 관리하고, 소스 코드에 직접 하드코딩하지 않습니다. 제가 CI/CD 파이프라인을 구축할 때 환경 변수를 적극 활용하여 민감 정보를 분리 관리했던 경험이 있습니다.
- 에러 메시지 일반화: 사용자에게 노출되는 에러 메시지는 일반적인 문구로 변경하고, 상세한 에러 로그는 서버 내부에만 기록합니다.
- 정기적인 보안 감사 및 취약점 스캔: 정기적으로 서버 및 애플리케이션의 보안 설정을 점검하고, 취약점 스캐너를 사용하여 설정 오류를 찾아냅니다.
Image by SylwesterL on Pixabay
실무에서 마주한 보안 위협과 대응 경험
개발 경력이 쌓이면서 다양한 규모의 프로젝트를 경험했고, 그 과정에서 수많은 보안 위협에 직면했습니다. 단순히 코드를 잘 짜는 것만으로는 부족하다는 것을 깨달은 순간들이었습니다.
한번은 외부 연동 모듈을 개발하면서 XML External Entity (XXE) 취약점과 유사한 상황을 겪었습니다. 외부에서 XML 데이터를 받아 파싱하는 로직이었는데, DTD(Document Type Definition)를 허용하도록 기본 설정이 되어 있었습니다. 다행히 실제 공격으로 이어지기 전에 QA 과정에서 발견하여 막을 수 있었죠. 이를 계기로 XML 파서 설정 시 외부 엔티티 참조를 비활성화(disableExternalEntities)하는 것이 얼마나 중요한지 깨달았습니다.
또 다른 사례는 ACL (Access Control List) 구현 오류였습니다. 특정 관리자 페이지에 접근 권한이 없는 일반 사용자가 URL을 직접 입력하여 접근할 수 있는 버그가 있었습니다. 이는 취약한 접근 제어(Broken Access Control)의 전형적인 예시였고, 모든 API와 페이지에 대해 권한 검증 로직을 철저히 추가하는 리팩토링 작업을 진행했습니다. 단순히 UI에서 메뉴를 숨기는 것만으로는 부족하며, 서버단에서 항상 권한을 확인해야 한다는 것을 다시 한번 상기시켜 주었습니다.
이러한 경험들을 통해 얻은 교훈은 다음과 같습니다.
- 보안은 개발 초기부터 고려해야 한다: 개발 막바지에 보안을 적용하는 것은 시간과 비용을 크게 증가시킵니다. 위협 모델링(Threat Modeling)을 개발 단계에 포함시키는 것이 중요합니다.
- 보안은 지속적인 과정이다: 한 번의 보안 점검으로 모든 것이 끝나는 것이 아닙니다. 새로운 취약점은 계속해서 발견되므로, 정기적인 업데이트와 모니터링이 필수적입니다.
- 개발자의 보안 인식 향상: 개발팀 전체가 보안에 대한 이해도를 높이는 것이 가장 중요합니다. 주기적인 보안 교육과 코드 리뷰를 통해 보안 결함을 조기에 발견하고 수정할 수 있습니다.
보안 취약점 점검 도구 활용 팁
수많은 웹 애플리케이션 보안 취약점을 수동으로 모두 찾아내는 것은 불가능에 가깝습니다. 효율적인 보안 관리를 위해 자동화된 도구들을 적극 활용하는 것이 좋습니다. 저 역시 개발 파이프라인에 다양한 보안 도구를 통합하여 사용하고 있습니다.
1. SAST (Static Application Security Testing)
SAST는 소스 코드를 분석하여 잠재적인 취약점을 찾아내는 도구입니다. 코드가 실행되기 전에 보안 결함을 발견할 수 있다는 장점이 있습니다. 대표적으로 SonarQube와 같은 도구가 있습니다. 제가 CI/CD 파이프라인에 SonarQube를 통합하여 사용한 결과, 개발자들이 커밋할 때마다 코드의 보안 취약점과 품질 문제를 자동으로 분석하여 리포트해 주었고, 이를 통해 보안 버그를 개발 초기에 수정하는 데 큰 도움이 되었습니다. 이는 수정 비용을 현저히 낮추는 효과가 있었습니다.
- 장점: 개발 초기 단계에서 발견, 전체 코드베이스 검사 가능.
- 단점: 오탐(False Positive) 가능성, 런타임 취약점 발견 어려움.
2. DAST (Dynamic Application Security Testing)
DAST는 실제로 애플리케이션을 실행시켜 외부에서 공격을 시도하는 방식으로 취약점을 찾아냅니다. 블랙박스 테스트와 유사하며, 런타임 환경에서 발생하는 취약점(예: 인증 문제, 세션 관리 문제)을 발견하는 데 효과적입니다. OWASP ZAP (Zed Attack Proxy)이나 Burp Suite 같은 도구들이 있습니다. 저는 OWASP ZAP을 사용하여 개발이 완료된 모듈을 대상으로 자동 스캔을 진행했고, 이를 통해 놓치기 쉬운 설정 오류나 세션 관련 취약점을 발견한 경험이 있습니다.
- 장점: 실제 공격과 유사한 방식으로 테스트, 런타임 취약점 발견 용이.
- 단점: 모든 코드 경로를 테스트하기 어려움, 개발 후반부에 사용 가능.
3. IAST (Interactive Application Security Testing)
IAST는 SAST와 DAST의 장점을 결합한 형태로, 애플리케이션이 실행되는 동안 내부 동작을 모니터링하여 취약점을 찾아냅니다. 코드 실행 경로를 추적하며 정확도가 높고 오탐이 적다는 장점이 있습니다. 아직 대중화되지는 않았지만, 차세대 보안 테스트 도구로 주목받고 있습니다.
이 외에도 WAF (Web Application Firewall)를 도입하여 외부 공격을 실시간으로 차단하거나, OSINT (Open Source Intelligence)를 활용하여 서비스와 관련된 공개된 민감 정보를 모니터링하는 등 다양한 방법을 병행하면 더욱 견고한 보안 환경을 구축할 수 있습니다.
Image by NickyPe on Pixabay
지속적인 보안 강화의 중요성
웹 애플리케이션 보안은 단발성 이벤트가 아니라 지속적인 노력과 관심이 필요한 영역입니다. 기술의 발전과 함께 공격 기법도 더욱 정교해지고 다양해지고 있기 때문입니다.
제가 경험한 바에 따르면, 가장 큰 보안 위협은 사람과 프로세스에서 오는 경우가 많았습니다. 개발자의 보안 인식 부족, 보안 업데이트 소홀, 변경 관리 미흡 등이 치명적인 결과를 초래할 수 있습니다. 따라서 다음과 같은 사항들을 꾸준히 실천하는 것이 중요하다고 생각합니다.
- 정기적인 보안 교육: 모든 개발자와 운영팀에게 OWASP Top 10을 포함한 웹 보안의 기본 원칙과 최신 동향에 대한 교육을 꾸준히 제공해야 합니다.
- 보안 코드 리뷰: 코드 리뷰 과정에 보안 전문가 또는 보안 지식이 있는 개발자를 참여시켜 잠재적인 취약점을 사전에 발견하고 수정합니다.
- 위협 모델링: 새로운 기능이나 서비스를 개발하기 전에 위협 모델링을 수행하여 발생 가능한 보안 위협을 식별하고 대응 방안을 마련합니다.
- 패치 및 업데이트: 사용 중인 프레임워크, 라이브러리, 운영체제, 웹 서버 등을 최신 버전으로 유지하고, 보안 패치가 발표되면 신속하게 적용합니다.
- 보안 모니터링: 웹 애플리케이션 방화벽(WAF) 로그, 시스템 로그, 접근 로그 등을 지속적으로 모니터링하여 비정상적인 접근이나 공격 시도를 탐지합니다.
마무리: 안전한 웹 서비스를 위한 우리의 노력
이 글을 통해 OWASP Top 10 기반의 웹 애플리케이션 보안 취약점들을 이해하고, 실무에서 적용할 수 있는 방어 전략에 대해 깊이 있게 다뤄보았습니다. 인젝션, 취약한 인증, XSS, 보안 설정 오류 등은 웹 서비스에서 가장 흔하게 마주할 수 있는 위협들이며, 철저한 이해와 방어책 적용만이 안전한 서비스를 보장할 수 있습니다.
제가 직접 겪었던 경험들을 공유하면서, 단순히 이론적인 지식을 넘어 "실제로 어떻게 적용하고 대응했는지"에 초점을 맞추고자 했습니다. 보안은 개발 과정의 일부가 아니라, 서비스의 생명 주기 전반에 걸쳐 함께 해야 할 필수 요소입니다. 개발자 한 사람 한 사람의 보안 인식이 높아지고, 이를 코드와 프로세스에 반영하려는 노력이 모일 때 비로소 견고하고 신뢰할 수 있는 웹 서비스를 만들 수 있습니다.
여러분의 웹 서비스는 지금 안전한가요? OWASP Top 10을 다시 한번 살펴보며 우리 서비스의 약점은 없는지 점검해 보는 시간을 가져보시기 바랍니다. 혹시 이 글에서 다루지 못한 다른 취약점이나, 여러분만의 효과적인 방어 전략이 있다면 댓글로 공유해 주세요. 함께 더 안전한 웹 환경을 만들어 나갈 수 있기를 기대합니다!