Angular 애플리케이션은 기본적으로 안전하며, 대부분의 보안 문제는 개발자가 이러한 내장된 보호 기능을 우회하면서 발생합니다. Angular는 DOM에 렌더링하기 전에 값을 자동으로 처리하는 sanitization 파이프라인을 가지고 있습니다. 이 파이프라인은 escaping, sanitizing, trusting을 구분하며, trusting은 자동 검사를 명시적으로 우회합니다. HTML, STYLE, URL, RESOURCE_URL의 네 가지 고유한 SecurityContext가 있으며, 각각 다른 위험 프로필과 처리를 가집니다. DomSanitizer는 입력을 sanitizing하거나 Safe* 타입을 사용하여 명시적으로 신뢰하는 데 사용됩니다. 안티 패턴은 신뢰할 수 없는 입력에 대한 보안을 우회하는 것을 포함하며, 이는 보안 검토에서 즉시 위험 신호를 발생시킵니다. 보안 우회는 때때로 정당화될 수 있지만, 신중한 고려와 위험에 대한 명확한 이해가 필요합니다. sanitization을 우회하지 않고 Markdown을 안전하게 렌더링하는 것이 더 나은 대안으로 제시됩니다. SafeResourceUrl은 신뢰할 수 있는 iframe 임베딩에 중요합니다. SafeUrl은 일반적으로 표준 anchor 태그에 필요하지 않습니다. Angular 애플리케이션의 CSRF 보호는 프론트엔드와 백엔드 간의 공유 책임입니다. HTTP Interceptors는 보안 적용 계층 역할을 할 수 있습니다. Content Security Policy와 Trusted Types는 프론트엔드 보안을 더욱 강화합니다. 이 글은 SSR 및 hydration 고려 사항도 다룹니다. 궁극적으로 보안은 프론트엔드와 백엔드 간의 분할 책임입니다. 일반적인 실수가 요약되고, 프로덕션 보안 검토 체크리스트가 제공되며, 마지막 생각은 Angular의 보안 모델과 함께 작업하는 것을 강조합니다.