당신의 웹사이트를 위한 보안 헤더: 보안과 SEO에 좋습니다

보안 헤더가 무엇이며 어떻게 작동하는지, 그리고 왜 당신의 웹사이트 보안에 중요한지, 그리고 당신의 SEO 조치에도 도움이 되는지에 대해 여기에서 배우세요.

보안 헤더에 관한 도움 문서는 다음 주제들을 포함합니다.

보안 헤더란 무엇인가요?

보안 헤더는 웹사이트나 웹 애플리케이션에서 사용되는 HTTP 헤더로, 다양한 유형의 공격과 보안 취약점에 대한 보호 및 보안을 강화하기 위해 사용됩니다. 이는 사용자와 데이터를 위협으로부터 보호하기 위한 중요한 보안 수단을 제공합니다. 

이것이 정말 필요한지 궁금하다면 온라인 도구를 사용하여 현재 보안을 테스트할 수 있습니다. 이것은 securityheaders.com에서 할 수 있습니다. 여기에 URL을 입력해보세요.

아마도 D 또는 F 결과를 받을 것입니다. 대부분의 웹사이트는 웹사이트 제작 또는 리뉴얼 과정에서 웹사이트의 보안이 거의 고려되지 않기 때문에 처음에는 성적이 안 좋을 수 있습니다. 어떻게 보안 헤더를 구현하는지 (개발자가 아닌 경우에도) 아래에서 알 수 있지만, 아직 당신에게 개선할 부분이 있음을 이미 알고 있습니다.

보안 헤더는 어떻게 작동하나요?

보안 헤더는 웹 서버가 웹사이트 또는 웹 애플리케이션에 대한 요청을 보낼 때 브라우저에게 보내는 HTTP 응답의 일부로 작동합니다. 이러한 헤더에는 브라우저에게 보안 및 개인 정보 보호에 대한 지침과 정보가 포함되어 있습니다. 다음은 몇 가지 중요한 보안 헤더와 그 작동 방식입니다.

HTTP Strict Transport Security (HSTS)

HSTS는 중간인 공격을 방지하기 위해 브라우저가 웹사이트와의 연결을 HTTPS로 설정하고 유지하도록 강요합니다. 

많은 웹사이트는 HTTP에서 HTTPS로의 단순한 301 리디렉션만 가지고 있습니다. 웹사이트 내용에 있는 링크 중 많은 것이 아직 HTTP로 되어 있습니다. 이런 링크를 클릭하면 먼저 HTTP 페이지가 로드되고 301 리디렉션이 활성화됩니다. 또는 브라우저에 https 부분을 입력하지 않고도 웹 사이트에 액세스하려 할 때 (대부분의 경우), 중간인 공격 가능성이 있습니다. 

HSTS는 공격자가 HTTPS 연결을 HTTP 연결로 변경하는 것을 방지하여 공격자가 안전하지 않은 리디렉션을 활용하는 것을 방지합니다. 따라서 안전한 HTTPS 연결을 통해 로드되도록 강제합니다.

X-Content-Type-Options

이 헤더는 지정된 유형이 올바르지 않을 때 브라우저가 자원의 MIME 유형을 추측하려고 시도하는지를 제어합니다. MIME 스푸핑 공격을 방지하는 데 도움이 되며, 올바른 MIME 유형을 가진 스타일 및 스크립트만을 로드합니다. 배경 지식: 브라우저는 웹사이트에서 다운로드할 수 있는 텍스트, 이미지 (.png), 비디오 (.mp4) 또는 HTML, 자바스크립트 및 기타 유형의 콘텐츠인지 스니핑할 수 있습니다.

"X-Content-Type-Options: nosniff" 사용은 특히 중요한 보안 조치이며, 특히 Cross-Site Scripting (XSS)와 같은 특정 공격 벡터를 방지하는 데 도움이 됩니다. XSS 공격에서 공격자는 PDF와 같은 자원에 악의적인 JavaScript 코드를 삽입하려고 시도할 수 있으며, 브라우저에 PDF로 속이고 MIME 유형이 다른 것을 가리켜 JavaScript 파일로 실행하도록 유도할 수 있습니다.

이는 웹사이트 방문자에게 잔악한 결과를 초래하며, 특히 드라이브 바이 다운로드 공격의 경우에는 사용자의 컴퓨터에 악성 코드가 설치될 수 있습니다.

"nosniff" 사용은 다른 보안 조치와 함께 (예: 내용 보안 정책 (CSP)) 사용되어 웹 응용 프로그램의 안전성을 향상시키고 공격 표면을 줄이는 데 중요합니다. 이 헤더는 일반적으로 해당 웹사이트의 모든 리소스 (예: HTML, JavaScript, CSS 파일)에 대한 HTTP 응답에 활성화되어야 합니다.

X-Frame-Options

이 헤더는 Clickjacking 공격을 방지하기 위해 웹 페이지가 HTML 프레임이나 iframe에 표시되는 것을 방지합니다. "X-Frame-Options" 사용은 투명한 프레임에 웹 사이트를 로드하고 사용자의 마우스 클릭을 악용하는 공격을 방지하는 중요한 보안 조치입니다. 헤더를 설정함으로써 웹 사이트 소유자는 웹 사이트가 프레임에 포함되는 방식을 제어할 수 있습니다.

"X-Frame-Options"은 Clickjacking을 방지하기 위한 오래된 방법으로 간주됩니다. 더 현대적인 접근 방식은 Clickjacking을 방지할 수 있고 추가적인 보안 측면을 다루는 "내용 보안 정책" 헤더 (CSP)를 사용하는 것입니다. 더 자세한 내용은 아래에서 확인하세요.

X-XSS-Protection

이 헤더는 브라우저의 내장 XSS 보호를 활성화하거나 비활성화합니다. 

Referrer-Policy

"Referrer-Policy"은 웹서버에서 웹브라우저가 HTTP 요청의 "Referrer" 필드 정보를 처리하는 방법을 지정하기 위해 보내는 HTTP 헤더입니다. "Referrer"는 일반적으로 사용자가 현재 페이지로 이동하기 전의 이전 페이지의 URL을 나타내는 HTTP 헤더 필드입니다. "Referrer-Policy"는 웹사이트 운영자가 다른 웹사이트로 Referrer 정보를 전달하는 것을 제어하고 사용자의 개인정보를 보호하는 방법을 제공합니다. 온라인 콘텐츠로 수익을 올리는 사람들에게 알아두면 좋은 점: Referrer-Policy는 제휴 링크에 영향을 주지 않습니다.

Content Security Policy (CSP)

CSP-헤더는 어떤 소스로부터 리소스(스크립트, 이미지 및 스타일시트)를로드 할 수 있는지를 지정합니다. 이는 사이트간 스크립팅(XSS), 코드 주입 및 유사한 공격을 방지하는 데 도움이 됩니다.

크로스사이트 스크립팅 (XSS) 공격은 악성 스크립트를 담아 사용자의 브라우저로 로드하도록 사용자의 CMS 또는 프레임워크의 보안 결함을 악용하는 방식으로 설계됩니다. 예를 들어, 이메일 양식이 안전하게 인코딩되지 않아 제한되지 않은 입력이 허용되는 경우 크로스사이트 스크립팅 공격 벡터가 될 수 있습니다. 잘못된 인코딩된 양식은 악성 파일 주입으로 이어질 수있습니다. 이것이 우리가 대부분의 고객 프로젝트를 완전히 연락 양식이없이 설치하는 이유 중 하나일 수도 있습니다.

CSP-헤더를 통해 사전 목록을 통해 웹사이트가 무엇을로드할 수 있고 무엇을로드할 수 없는지 설정합니다. 신뢰할 수있는 그룹 외부 서버에서 악성 스크립트를 로드하는 모든 공격자는 차단됩니다. 2016 년 12 월, CSP level 2로 Content Security Policy가 개발되어 hash-source, nonce-source 및 다섯 개의 새로운 지시문이 추가되었습니다. 브라우저 측면에서는 이로 인한 문제가 예상되지 않으며, 2023 년 9 월 11 일 현재로서 CSP 2는 브라우저의 95 %와 호환됩니다.

콘텐츠 보안 정책 작성은 당신이 설정하는 대로 강하거나 약할 수 있습니다. TutKit.com에서 모든 헤더 중에서 실제로 가장 오래 걸렸습니다, 외부에서 로드하는 모든 스크립트 및 리소스를 나열하고 화이트리스트에 추가할 수 있어야 했기 때문입니다. 올바른 통합을 확인하는 것은 securityheaders.com, Mozilla Observatory 및 Google PageSpeed Insight의 Best Practices 섹션에서 확인할 수 있습니다. Mozilla 서비스의 장점은 URL이 다른 외부 테스트 도구에서도 동시에 테스트되는 것입니다. 하나라도 감지되면 추가 탐색이 필요합니다.

보안 헤더는 왜 중요한가?

보안 헤더는 웹사이트와 웹애플리케이션의 공격 가능한 표면을 줄이고 알려진 보안 취약점을 해결하는 데 도움이 됩니다. 브라우저에게 보안에 관련된 명령을 제공하여 다양한 유형의 공격을 예방하거나 어렵게 만들 수있습니다. 이는 XSS 공격, 클릭재킹, MIME 스푸핑 및 기타 보안 문제를 포함합니다.

신용카드 거래를 저장, 전송 또는 처리하는 온라인 상점은 PCI-DSS 준수해야합니다. 많은 PCI-DSS 감사에서 HSTS(HTTP Strict Transport Security) 및 기타 보안 헤더도 검토됩니다. 여러분의 웹사이트가 PCI 준수 사항에 해당되어 실제로 신용 카드 거래를 처리하고 결제 공급업체가 여러분에게 PCI 인증을 요구하며 테스트/감사를 통해 증명해야 할 경우, 보안 헤더 추가는 중요한 주제가 될 것입니다.

세 번째로, 사용자 경험을 보장하고 SEO 조치에 긍정적인 효과를 줍니다. 아래에서 더 자세히 설명하겠습니다.

어떻게 보안 헤더를 구현할까요?

보안 헤더를 구현하려면 일반적으로 웹서버 또는 웹애플리케이션 수준의 구성 변경이 필요합니다.

1. 먼저 필요한 보안 헤더 확인: 웹사이트 또는 웹애플리케이션에 가장 중요한 보안 헤더를 고려해보세요. 선택은 특정 요구 사항 및 위협에 따라 다릅니다. 쿠키와 연락 양식이 없는 단일 페이지만 있는 경우 HTML 기반이기 때문에 위험이 낮습니다. 그러나 쿠키, 신용카드 데이터 전송, 고객 데이터 및 CMS가 있는 쇼핑몰의 경우 위험이 높을 것입니다.

2. 웹서버 구성: 대부분의 보안 헤더는 웹서버 구성을 조정하여 추가 할 수 있습니다. 예를 들어, Apache 서버는 .htaccess 파일에서 헤더를 구성하고, Nginx는 nginx.conf 파일이나 sites-available을 사용합니다.

3. HTTP 응답 헤더에 헤더 설정: 헤더는 웹사이트나 웹애플리케이션의 HTTP 응답 헤더에 설정되어야 합니다. 일반적으로 서버 모듈, 스크립트 또는 미들웨어를 사용하여 이를 실현할 수 있습니다.

4. 구현 테스트: 보안 헤더를 추가한 후 웹 사이트나 웹 애플리케이션을 완전히 테스트하여 모든 것이 예상대로 작동하는지 확인해야 합니다. 웹사이트의 보안 구성을 분석할 수 있는 Security Headers 및 Mozilla Observatory와 같은 온라인 도구도 있습니다.

5. 헤더를 최신 상태로 유지: 보안 헤더를 꾸준히 모니터링하고 업데이트하여 최신 권장 사항을 준수하고 새로운 위협으로부터 안전한지 확인하세요.

보안 헤더 구현 절차는 웹 서버 기술과 플랫폼에 따라 달라질 수 있으므로 서버 및 웹 애플리케이션 설명서를 참조하거나 전문적인 지원을 받는 것이 좋습니다. 아래는 Apache 및 Nginx 서버에 구현하는 방법에 대한 안내서가 제공됩니다. 비개발자로서 WordPress 플러그인을 사용하여 구성하는 것만큼 서버 측에서는 쉽지 않습니다.

Apache 서버에서 .htaccess를 통한 보안 헤더 삽입

.htaccess 파일을 통해 보안 헤더를 추가하는 것은 Apache 웹 서버의 웹사이트 보안을 높이는 일반적인 방법입니다. .htaccess 파일을 사용하면 서버 전반적인 설정과 구성, 보안 헤더를 포함한 것들을 설정할 수 있습니다. 다음은 .htaccess 파일을 통해 보안 헤더를 추가하는 단계별 안내입니다.

백업 만들기: 변경하기 전에 웹사이트를 보호하고 .htaccess 파일의 백업을 만들어 변경으로 인해 웹사이트에 액세스할 수 없게 되는 일이 없도록 합니다.

.htaccess 파일 열기: .htaccess 파일은 일반적으로 WordPress 설치 폴더의 루트 디렉터리에 있습니다. 메모장++, Dreamweaver, PHP Storm 또는 Visual Studio Code와 같은 텍스트 편집기로 열 수 있습니다.

보안 헤더 추가: 보안 헤더를 추가하려면 .htaccess 파일에서 Header 지시문을 사용하십시오. 자주 사용되는 보안 헤더 예시와 추가 방법은 다음과 같습니다:

콘텐츠 보안 정책 (CSP):

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:; style-src 'self' 'unsafe-inline';"

X-콘텐츠-유형-옵션:

Header always set X-Content-Type-Options "nosniff"

X-프레임-옵션:

Header always set X-Frame-Options "DENY"

X-XSS-보호:

Header always set X-XSS-Protection "1; mode=block"

HTTP 엄격한 전송 보안 (HSTS):

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Referrer-Policy:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

.htaccess 파일 저장: 원하는 보안 헤더를 추가한 후 .htaccess 파일을 저장하고 필요하면 웹 서버에 업로드하십시오.

구성 검토: .htaccess 파일에서 구문 오류가 없는지 확인하고 웹사이트를 방문하고 오류 메시지를 확인하여 확인할 수 있습니다. 또한 사이트의 보안 헤더 효과를 검토하기 위해 온라인 도구를 사용할 수 있습니다.

웹사이트 테스트: 웹사이트가 제대로 작동하는지 그리고 보안 헤더가 원하는 보안 조치를 적용하는지 확인하세요.

Apache 서버에 .htaccess 파일을 통해 보안 헤더를 추가하는 것은 가능하지만, Nginx와 같은 서버에서는 작동하지 않습니다. Nginx와 같은 다른 웹 서버를 사용하는 경우 웹서버에 해당하는 설정 파일을 편집하여 보안 헤더를 설정해야 합니다. 자세한 내용은 이어지는 부분을 참조해 주세요 ...

Nginx 서버에서 보안 헤더 삽입

Nginx에서 보안 헤더를 추가하는 방법은 일반적으로 Nginx의 구성 파일을 통해 이루어지며, 일반적으로 .conf 확장자의 파일에 저장됩니다. Nginx에서 보안 헤더를 삽입하는 단계별 안내는 다음과 같습니다:

백업 만들기: Nginx 구성을 변경하기 전에 구성 파일의 백업을 만들어 문제가 발생한 경우 작동하는 구성으로 되돌릴 수 있도록 합니다.

Nginx 구성 파일 열기: Nginx의 주 구성 파일은 Linux 시스템의 /etc/nginx/ 디렉토리에 일반적으로 있습니다. 시스템에 따라 구체적인 파일이 다를 수 있지만 보통 nginx.conf 또는 각 웹사이트에 대한 default 또는 sites-available로 이름 지어진 파일로 알려져 있습니다.

텍스트 편집기나 터미널 편집기 (예: nano, vim, gedit)를 사용하여 구성 파일을 엽니다. 파일을 편집하려면 루트 또는 슈퍼유저 권한이 필요합니다.

원하는 보안 헤더를 추가하십시오: add_header 지시문을 사용하여 Nginx 구성에 원하는 보안 헤더를 추가할 수 있습니다. 일반적으로 사용되는 몇 가지 보안 헤더의 예는 다음과 같습니다:

콘텐츠 보안 정책 (CSP):

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:; style-src 'self' 'unsafe-inline';";

X-Content-Type-Options:

add_header X-Content-Type-Options "nosniff";

X-Frame-Options:

add_header X-Frame-Options "DENY";

X-XSS-Protection:

add_header X-XSS-Protection "1; mode=block";

HTTP Strict Transport Security (HSTS) (주의: 웹 사이트가 항상 HTTPS로 접근 가능한 경우에만 사용):

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";

Referrer-Policy:

add_header Referrer-Policy "strict-origin-when-cross-origin";

구성 파일을 저장하고 닫으십시오: 원하는 헤더를 추가한 후에는 구성 파일을 저장하고 닫으십시오.

구성을 확인하세요: Nginx 구성의 유효성을 nginx -t 명령으로 확인할 수 있습니다. 구성이 올바르면 성공 메시지가 표시됩니다.

Nginx를 시작하거나 업데이트하세요: 구성을 확인한 후에는 새 헤더를 활성화하기 위해 Nginx 서버를 시작하거나 업데이트하세요. Debian/Ubuntu에서는 sudo service nginx restart, systemd 기반 시스템에서는 sudo systemctl restart nginx 명령으로 서버를 재시작할 수 있습니다.

웹 사이트를 테스트하세요: 모든 기능이 올바르게 작동하고 보안 헤더가 원하는 보안 조치를 적용하는지 확인하기 위해 웹 사이트를 테스트하세요.

Nginx 구성은 시스템에 따라 다를 수 있으며, 특히 여러 개의 가상 호스트(서버 블록)나 더 복잡한 구성을 사용하는 경우에는 더욱 다를 수 있습니다. 따라서 사이트에 해당하는 올바른 구성 파일을 수정하는지 확인하세요.

WordPress 플러그인을 사용한 Security Headers

WordPress 웹 사이트에 Security Headers를 설정하는 데 도움을 주는 다양한 WordPress 플러그인이 있습니다. 이러한 플러그인을 사용하면 보안 조치를 구현하는 프로세스를 단순화할 수 있으며, 기술적인 지식이 없어도 수행할 수 있습니다.

"Headers Security Advanced & HSTS WP" 플러그인은 WordPress 웹 사이트에서 보안 헤더와 HTTP Strict Transport Security (HSTS)를 구현하는 데 특화되어 있습니다. 이 플러그인은 이러한 헤더와 보안 조치를 구성하는 사용자 친화적인 방법을 제공합니다.
https://de.wordpress.org/plugins/headers-security-advanced-hsts-wp/

다음은 WordPress 플러그인을 사용하여 Security Headers를 설정하는 데 도움이 되는 몇 가지 플러그인입니다:

1. WP Security Headers: 이 플러그인을 사용하면 WordPress 웹 사이트에서 다양한 Security Headers를 구성할 수 있습니다. 사용자 친화적인 인터페이스를 제공하며 Content Security Policy (CSP), X-Frame-Options 등과 같은 헤더를 조정할 수 있습니다.

2. HTTP Headers: HTTP Headers는 WordPress 플러그인으로, 보안과 개인 정보 보호를 위해 다양한 HTTP 헤더를 설정할 수 있습니다. X-Content-Type-Options, X-XSS-Protection, Referrer-Policy와 같은 헤더를 구성할 수 있습니다.

3. Security Headers: 이 플러그인은 Content Security Policy (CSP)를 설정하는 데 특화되어 있습니다. 웹 사이트에 대한 CSP 정책을 간단히 설정하고 조정하는 방법을 제공합니다.

4. Easy Security Headers: 이 플러그인은 WordPress에서 중요한 Security Headers를 활성화하고 구성할 수 있는 간편한 방법을 제공합니다. Content Security Policy, Strict-Transport-Security, X-Content-Type-Options 등을 포함합니다.

WordPress에서 보안 헤더를 설정하는 데 플러그인을 사용하기 전에 WordPress 버전과 PHP 버전과 호환되는지 확인해야 합니다.

Headless CMS Strapi에 대한 Security Headers 구현

Strapi는 Node.js를 기반으로 하는 인기 있는 Headless-CMS(콘텐츠 관리 시스템)입니다. WordPress와 마찬가지로 Strapi에서도 Security Headers를 구현할 수 있습니다. Strapi에서는 서버 측 응용 프로그램이기 때문에 Security Headers를 설정하는 과정은 일반적으로 깊은 수준에서 이루어집니다. Strapi 애플리케이션에 Security Headers를 구현하는 단계는 다음과 같습니다:

미들웨어 사용하기: Strapi에서는 HTTP 헤더를 설정하기 위해 미들웨어를 사용할 수 있습니다. 원하는 Security Headers를 HTTP 응답에 추가하는 사용자 정의 미들웨어를 생성할 수 있습니다. 다음은 그 예시입니다:

1. 미들웨어 디렉토리에 security-headers.js와 같은 파일을 생성합니다.

module.exports = (strapi) => {
return {
initialize() {
strapi.app.use(async (ctx, next) => {

2. 원하는 Security Headers를 설정합니다.

ctx.set('Content-Security-Policy', "default-src 'self'"); ctx.set('X-Content-Type-Options', 'nosniff'); ctx.set('X-Frame-Options', 'DENY'); ctx.set('X-XSS-Protection', '1; mode=block'); ctx.set('Strict-Transport-Security', 'max-age=63072000; includeSubDomains; preload'); ctx.set('Referrer-Policy', 'strict-origin-when-cross-origin');

3. 다음 미들웨어 단계를 호출합니다.

await next(); 
}); 
},
};
};

미들웨어 등록: 미들웨어를 생성한 후, Strapi 애플리케이션의 middleware.js 파일에 등록하여 HTTP 요청마다 실행되도록 합니다.

module.exports = {
settings: {

기타 설정 ...

},
middleware: {

기타 미들웨어 ...

securityHeaders: { 
enabled: true, 
},
},
};

맞춤 및 테스트: 미들웨어에서 헤더 값을 요구에 맞게 조정하고, 응용 프로그램을 테스트하고 보안 헤더 확인 도구와 같은 도구를 사용하여 헤더가 올바르게 설정되었는지 확인합니다.

서버 구성 검토: Strapi에서의 미들웨어 설정 외에도, Web 서버(Nginx 또는 Apache)에도 Strapi에서 설정한 것을 덮어쓸 수 있는 모순된 헤더가 없는지 확인하는 것이 중요합니다.

당신의 Strapi 구성 및 서버에 따라 구현이 달라질 수 있습니다. Strapi CMS에서는 config/app.js를 통해 대체로 구현할 수 있습니다. 하지만 미들웨어 를 통한 방식은 더 많은 통제력과 유연성을 제공합니다.

4eck-media.de 에이전시 웹 사이트에서 Strapi Headless CMS를 사용하는 것은 다음과 같습니다:

웹 사이트의 보안 헤더 및 보안 취약점을 위한 테스트 도구

Security Header를 구현한 경우, 여러 브라우저와 기기로 웹 사이트의 기능 테스트를 꼭 해보세요. 또한 모든 것이 올바르게 통합되었는지 확인하는 데 다음 두 가지 테스트 도구를 사용하세요:

• securityheaders.com => 이 도구는 특히 Security Header를 테스트합니다. 위 스크린샷을 참조하세요.
• securityscan.getastra.com => 이 도구는 140가지 이상의 보안 취약점을 테스트하며, Security Header도 포함됩니다.

지금은 tutkit.com에 대한 https://securityscan.getastra.com/ 을 통한 헬스 체크에서 90/100의 값이 나왔습니다:

모든 것이 괜찮지만 더 나은 점을 찾을 수 있습니다. 우리는 특정 모듈들로 인해 일반적인 보안 요구 사항과 다르게 JavaScript를 생성하는 문제가 있습니다. vue.js 및 TutKit.com의 Laraberg 모듈의 다음 주요 업데이트로 이 문제를 해결할 예정입니다.

SEO (검색엔진 최적화)에 보안 헤더가 유용한가요?

보안 헤더와 SEO (검색엔진 최적화) 사이에는 간접적인 연결이 있습니다.

Google은 2021년에 페이지 경험을 품은 일곱 가지 다른 요인들을 하나로 묶고 웹 사이트 경험의 품질을 보여주는 통합 이미지를 형성한다고 밝혔습니다.

HTTPS 및 안전한 탐색 은 페이지 경험에 대한 긍정적인 신호 중요한 요소입니다. Google에서 HTTPS의 사용도 랭킹 요인으로 언급했습니다. 초기에는 안전한 탐색 또한 동일하게 적용되었습니다. 하지만 2021년 8월 Google은 다시 점검한 결과, 많은 웹 사이트 소유자가 해킹에 대해 아무런 책임이 없다는 이유로 안전한 탐색을 더 이상 랭킹 요인으로 고려하지 않기로 결정했습니다. 

Dev-Tools의 PageSpeed Insights 및 Lighthouse 테스트에서 안전한 탐색에 대한 권고 사항이 나타납니다. 따라서 안전한 탐색 문제가 SEO에 대해 아직 해결되지 않았을 수 있다는 점을 유의해야 합니다:

또한 Google은 EEAT 원칙을 준수하는 웹 사이트를 더 높게 가중 평가하며, 이는 즉 전문성, 경험, 권위 및 신뢰성이 검증된 콘텐츠를 말합니다. 신뢰성은 웹 사이트나 웹 콘텐츠의 신뢰성과 신뢰성을 의미합니다. Google은 개인 정보 보호, 보안 및 투명성과 같은 요소에 따라 신뢰성을 평가합니다.

보안 헤더와 SEO의 정확한 연결은 당신의 웹 사이트 및 방문자들을 위한 다섯 가지 HTTP 헤더의 이점을 통해 명확해집니다:

1. 신뢰와 안전성: 보안 헤더를 사용하는 웹 사이트는 방문자들과 검색 엔진에게 사용자 및 데이터의 안전을 중요시한다는 신호를 보냅니다. 이는 사용자의 웹 사이트에 대한 신뢰를 높일 수 있고 데이터 누출 및 악성 코드 공격과 같은 보안 문제의 위험을 줄일 수 있습니다.

2. 보안 문제 예방: 보안 헤더, 예를 들어 콘텐츠 보안 정책 (CSP)와 X-XSS-Protection과 같은 헤더는 Cross-Site Scripting (XSS)와 같은 알려진 보안 취약점을 방지하는 데 도움이 됩니다. 보안 문제에 취약한 웹 사이트는 검색 엔진에 의해 패널티를 받거나 사용자에 대한 경고 메시지에 나타날 수 있어 SEO에 부정적인 영향을 줄 수 있습니다.

3. 로딩 시간 개선: HTTP Strict Transport Security (HSTS)와 같은 일부 보안 헤더는 웹 사이트의 로딩 시간을 개선하는 데 도움이 될 수 있습니다. 이는 브라우저가 HTTPS를 통해 연결을 강제하기 때문에 따르는 것입니다. 더 빠른 로딩 시간은 Google과 같은 검색 엔진이 랭킹 기준으로 고려하는 중요한 요소입니다.

4. 클릭재킹 및 사기 방지: X-Frame-Options와 같은 보안 헤더는 웹 사이트 콘텐츠가 가시적 프레임에서 표시되는 클릭 재킹 공격을 방지하는 데 도움을 줄 수 있습니다. 이는 웹 사이트에 대한 사용자의 신뢰를 높이고 사기 공격 발생 가능성을 줄일 수 있습니다.

5. HTTPS 및 랭킹: 보안 헤더와 직접적으로 연결되지는 않지만 HSTS와 같은 헤더를 통한 HTTPS 사용은 중요한 SEO 요소입니다. Google은 이미 2010년에 HTTPS를 랭킹 신호로 고려했음을 발표하였으며 HTTPS를 사용하는 웹 사이트는 SEO에서 이점을 얻을 수 있습니다.

Security Headers 사용은 나에게서 볼 때 웹 사이트의 SEO 랭킹에 긍정적인 영향을 줄 수 있지만 이는 유일한 기준이 아니며, 전체 보안 및 SEO 방정식의 아주 작은 부분에 불과합니다. 무관련한 콘텐츠나 불충분한 사용자 경험을 제공하는 웹 사이트는 보안 헤더를 추가함으로서만 검색 결과에서 더 나은 성과를 거두지 못할 것입니다. SEO는 고품질 콘텐츠, 우수한 사용자 경험, 모바일 최적화 등 여러 요소를 고려하는 복합 과정이며, 최종적으로 사용자의 신뢰를 얻고 웹 사이트를 보다 안전하게 만드는 중요한 성분이 보안 헤더입니다. 그 결과가 SEO 랭킹에 긍정적으로 영향을 줄 수 있습니다.

또한 역으로 말하자면: 웹 사이트에 악성 코드가 감염되어 Google이 웹 사이트 방문자에게 경고 메시지를 표시하는 경우, 귀하는 직접적인 평판에 부정적인 영향을 받습니다. 랭킹이 하락하고 이전의 모든 SEO 성과도 함께 소멸합니다. Google은 이러한 경우에 대해 검색 콘솔을 통해 귀하에게 알림을 보내며, 대체로 여기서도 악성 코드 감염 웹 사이트를 테스트할 수 있습니다.

우리는 최근 Security Sprint에서 보안 헤더를 최신 상태로 업그레이드하여 자랑스럽게 Hall of Fame에 들어갔습니다:

결론: Security Header를 구현하는 것은 로켓 과학이 아니며, 웹 사이트를 출시할 때마다 고려해야 합니다. 그러나 대부분의 웹 사이트 운영자, 기관 및 SEO 전문가들이 이를 간과하고 있어서 SEO 도구들이 HTTP 헤더에 대한 질의를 자사의 감사에 포함하는 것이 좋을 것입니다. 우리는 기대할 수 있습니다... 에게 요청하였습니다: SEOBILITY의 경영진에게 이 사항을 이미 제안하였습니다 :-)