사이드 프로젝트, 보안 벤더의 오탐으로 차단된 사연
개인 프로젝트인 Engramma가 피싱(Phishing) 의심으로 인해 브라우저에 의해 차단됨
구글 세이프 브라우징(Google Safe Browsing) 해제 후에도 다수의 보안 벤더(Security Vendors)에 의해 차단되는 문제 발생
각 벤더에 오탐 신고(False Positive Report)를 진행했으나, 긴 처리 시간과 불투명한 과정으로 어려움 겪음
302 리다이렉트(302 Redirect) 사용이 원인으로 추정, 랜딩 페이지(Landing Page) 구축을 통해 문제 해결
자동화된 보안 시스템의 문제점
저자는 사이드 프로젝트가 피싱(Phishing) 의심으로 차단된 후, 구글(Google)의 조치를 따랐음에도 불구하고 여러 보안 벤더(Security Vendors)에 의해 차단되는 문제를 겪었다. 특히, 자동화된 시스템은 오탐(False Positive)에 취약하며, 벤더별로 상이한 신고 절차와 긴 처리 시간은 개발자에게 큰 부담을 준다. 자동화된 시스템(Automated Systems)은 웹 트래픽(Web Traffic)에 의존하는 비즈니스에 심각한 피해를 줄 수 있다.
302 리다이렉트(302 Redirect)의 함정
저자는 초기 사이트 구축 시 302 리다이렉트(302 Redirect)를 사용하여 랜딩 페이지(Landing Page)를 우회했다. 하지만, 보안 시스템은 이러한 리다이렉트를 악의적인 행위로 간주하여 사이트를 차단했다. 이는 새로운 도메인(Domain)을 사용하는 경우 더욱 쉽게 감지될 수 있다. 302 리다이렉트(302 Redirect)는 SEO(Search Engine Optimization)에 안전하다고 생각했지만, 보안 측면에서는 위험 요소로 작용할 수 있다.
대응 과정에서의 어려움
저자는 여러 보안 벤더에 오탐 신고를 진행하면서, 각기 다른 신고 절차와 불투명한 처리 과정에 어려움을 겪었다. 일부 벤더는 계정 생성(Account Creation)을 요구하거나, AI 챗봇(AI Bot)을 통해 기술 지원을 받기 어렵게 만들었다. 또한, 응답이 없거나, 늦어지는 경우도 발생했다. 이러한 비효율적인 대응 방식은 개발자에게 시간 낭비와 좌절감을 안겨준다. 오탐 신고 절차(False Positive Reporting Process)의 개선이 필요하다.
사전 예방의 중요성
저자는 사이트 출시 전에 바이러스토탈(VirusTotal)을 통해 보안 검사를 수행하고, 구글 서치 콘솔(Google Search Console)을 설정하는 등 사전 예방의 중요성을 강조한다. 또한, 도메인 상태를 지속적으로 모니터링(Monitoring)하고, 문제가 발생했을 때 신속하게 대응해야 한다고 조언한다. 사전 점검(Preemptive Check)을 통해 잠재적인 문제를 미리 파악하고, 피해를 최소화할 수 있다.