web.config

web.config 파일의 최상위 루트 요소는 <configuration> 요소이다. 이 요소는 파일 내 모든 구성 설정을 감싸는 컨테이너 역할을 하며, XML 문서의 필수적인 구조적 틀을 제공한다. <configuration> 요소 내에는 다양한 섹션과 요소들이 계층적으로 배치되어, ASP.NET 애플리케이션의 인터넷 정보 서비스 환경에서의 구체적인 동작 방식을 정의한다.

이 요소는 특정한 네임스페이스 선언을 포함할 수 있으며, 이는 사용자 정의 구성 섹션이나 .NET 프레임워크의 특정 버전에 따른 설정을 정확히 참조하는 데 필요하다. 구성 파일의 핵심 구조는 <configuration> 아래에 <system.web>, <appSettings>, <connectionStrings>와 같은 주요 섹션 그룹이 직접적으로 또는 섹션 핸들러를 통해 배치되는 형태로 이루어진다.

<configuration> 섹션의 정확한 구조와 허용되는 하위 요소는 마이크로소프트의 공식 스키마 파일에 의해 정의된다. 이 스키마는 비주얼 스튜디오 같은 개발 도구에서 인텔리센스와 구문 검사를 제공하는 기준이 되어, 개발자가 구성 설정을 작성할 때 오류를 줄이고 표준 형식을 유지할 수 있도록 돕는다. 따라서 모든 유효한 web.config 파일은 반드시 하나의 <configuration> 루트 요소로 시작하고 끝나야 한다.

system.web 섹션은 web.config 파일의 핵심 구성 영역으로, ASP.NET 웹 애플리케이션의 런타임 동작을 광범위하게 제어하는 설정을 포함한다. 이 섹션은 HTTP 모듈, HTTP 처리기, 세션 상태, 인증, 컴파일 옵션 등 애플리케이션의 기본적인 작동 방식을 정의한다. 인터넷 정보 서비스(IIS)는 이 설정들을 읽어 해당 웹 애플리케이션을 호스팅할 때 적용한다.

주요 구성 요소로는 httpModules 및 httpHandlers가 있으며, 이들은 들어오는 HTTP 요청을 처리하는 파이프라인을 구성한다. 또한 authentication 요소를 통해 폼 인증, Windows 인증 등의 방식을 설정하고, sessionState 요소를 통해 세션 데이터의 저장 모드(InProc, StateServer, SQLServer)와 타임아웃을 관리할 수 있다. compilation 요소는 디버그 모드 활성화 여부나 .NET 프레임워크 타겟 버전을 지정하는 데 사용된다.

이 섹션의 설정은 애플리케이션의 성능과 보안에 직접적인 영향을 미친다. 예를 들어, customErrors 모드를 설정하면 사용자에게 노출되는 오류 정보의 수준을 제어할 수 있고, trace 설정을 비활성화하면 성능 저하와 민감한 정보 노출을 방지할 수 있다. 따라서 system.web 섹션의 구성은 웹 애플리케이션 배포 전에 신중하게 검토되어야 한다.

appSettings 섹션은 웹 애플리케이션에서 사용되는 애플리케이션별 구성 설정을 저장하는 데 사용되는 web.config 파일의 핵심 구성 요소이다. 이 섹션은 <appSettings> 요소로 정의되며, 주로 개발자가 코드 내에서 하드코딩하기보다 외부에서 관리하고 싶은 문자열, 연결 정보, 기능 플래그, API 키 등의 사용자 정의 키-값 쌍을 저장하는 용도로 활용된다. 이를 통해 설정값을 코드와 분리함으로써, 환경(개발, 테스트, 운영)에 따라 다른 값을 쉽게 적용할 수 있고, 설정 변경 시 애플리케이션을 재컴파일하지 않고도 web.config 파일만 수정하여 반영할 수 있다는 장점이 있다.

구조는 매우 직관적이며, <add> 요소를 사용해 key와 value 속성으로 구성된 여러 항목을 추가하는 방식이다. 예를 들어, 외부 API의 기본 URL이나 특정 기능의 활성화 여부를 나타내는 플래그를 설정할 수 있다. ASP.NET 애플리케이션 코드에서는 System.Configuration.ConfigurationManager.AppSettings 컬렉션을 통해 이 값을 쉽게 읽어올 수 있다. 이는 전역적으로 접근 가능한 정적 속성으로, 키 이름을 지정하여 해당 값을 문자열 형태로 조회하는 방식으로 동작한다.

appSettings 섹션에 저장되는 정보는 주로 민감하지 않은 일반 구성 데이터에 적합하다. 그러나 데이터베이스 연결 문자열과 같이 보안이 중요한 정보는 별도의 <connectionStrings> 섹션에 저장하는 것이 일반적이며, 해당 섹션은 더 강력한 보호 기능을 제공한다. appSettings에 민감한 정보를 저장해야 할 경우, Microsoft는 설정 값을 암호화하는 기능을 제공하여 구성 파일 내부에서 평문으로 노출되는 것을 방지할 수 있다.

이 섹션의 설정은 계층적인 web.config 파일 구조를 따라 상속될 수 있다. 즉, 루트 애플리케이션의 web.config에 정의된 appSettings는 하위 디렉터리의 애플리케이션에도 적용되며, 하위 디렉터리의 web.config 파일에서 동일한 키에 대한 값을 재정의할 수 있다. 또한 <location> 요소를 사용하면 특정 경로나 리소스에 대해서만 다른 appSettings 값을 적용하는 세밀한 제어도 가능하다.

connectionStrings 섹션은 웹 애플리케이션이 데이터베이스나 다른 외부 리소스에 연결하는 데 필요한 연결 문자열을 중앙 집중식으로 정의하고 관리하는 데 사용된다. 이 섹션은 web.config 파일 내 <configuration> 루트 요소의 직속 자식으로 위치하며, 애플리케이션 코드에서 프로그래밍 방식으로 쉽게 접근할 수 있도록 설계되었다. 각 연결 문자열은 고유한 이름(name 속성)과 실제 연결 정보를 담은 문자열(connectionString 속성)로 구성되며, 필요에 따라 공급자 정보(providerName 속성)를 지정할 수 있다.

주요 구성 요소로는 add, remove, clear 요소가 있다. add 요소는 새로운 연결 문자열을 추가할 때 사용되며, name과 connectionString 속성은 필수이다. remove 요소는 상위 구성 파일에서 상속된 특정 이름의 연결 문자열을 제거하는 데, clear 요소는 현재 수준에서 모든 상속된 연결 문자열을 지우는 데 사용된다. 이를 통해 계층적인 구성 파일 구조에서 유연하게 설정을 재정의할 수 있다.

이 섹션의 가장 큰 장점은 보안과 유지보수성에 있다. 데이터베이스 서버 주소, 인증 정보 등 민감한 연결 정보를 소스 코드에서 분리하여 관리할 수 있다. 따라서 개발, 테스트, 운영 등 서로 다른 환경에 맞춰 web.config 파일을 변환하거나 별도의 외부 파일을 참조하는 방식으로 배포를 단순화할 수 있다. 또한, Windows의 DPAPI(데이터 보호 API)나 ASP.NET의 aspnet_regiis 도구를 이용해 connectionStrings 섹션 전체를 암호화하여 설정 파일 내 평문 저장 위험을 줄일 수 있다.

실제 사용 시에는 ADO.NET을 비롯한 .NET Framework의 데이터 액세스 기술에서 System.Configuration.ConfigurationManager.ConnectionStrings 컬렉션을 통해 연결 문자열을 이름으로 검색하여 가져온다. 이때 providerName이 지정되면 엔터티 프레임워크(Entity Framework)나 특정 데이터베이스 공급자가 해당 정보를 사용할 수 있다. connectionStrings 섹션은 시스템 웹(system.web) 섹션의 세션 상태를 SQL Server에 저장하도록 구성할 때도 내부적으로 참조된다.

web.config 파일의 system.web 섹션 내에서는 웹 애플리케이션의 보안 정책을 정의하는 authentication과 authorization 요소를 구성할 수 있다. 이 설정들은 사용자가 누구인지 확인하고, 특정 리소스에 대한 접근 권한을 제어하는 핵심 메커니즘을 제공한다.

authentication 요소는 애플리케이션이 사용자를 인증하는 방식을 지정한다. 주로 사용되는 모드는 Windows, Forms, Passport, None이다. 예를 들어, Forms 인증을 사용할 경우, 사용자 자격 증명을 확인하는 로그인 페이지의 URL과 인증 쿠키의 이름, 만료 시간 등을 설정할 수 있다. 이를 통해 사용자 이름과 비밀번호를 기반으로 한 커스텀 로그인 시스템을 쉽게 구현할 수 있다.

인증된 사용자가 특정 페이지나 디렉터리에 접근할 수 있는 권한을 제어하려면 authorization 요소를 사용한다. 이 요소 내부의 allow와 deny 규칙을 조합하여 접근 제어 목록을 정의한다. 규칙은 사용자 이름(users 속성)이나 사용자가 속한 역할(roles 속성)을 기준으로 설정할 수 있으며, 와일드카드(*는 모든 사용자, ?는 익명 사용자)를 활용할 수 있다. 예를 들어, 관리자 디렉터리에 대해 일반 사용자의 접근을 차단하고 특정 역할 그룹만 허용하는 정책을 구성할 수 있다.

이러한 인증 및 권한 부여 설정은 애플리케이션 전역에 적용되거나, location 요소를 사용하여 특정 파일이나 디렉터리 경로에만 적용되도록 세밀하게 제한할 수 있다. 또한, Windows 인증과 Active Directory를 연동하거나, 외부 공급자를 통한 OAuth 인증과 같은 고급 시나리오를 지원하기 위한 구성도 가능하다.

web.config 파일 내의 system.web 섹션에서 sessionState 요소를 구성하여 세션 상태 관리 방식을 제어한다. 이 설정은 사용자 세션 데이터를 어디에, 어떻게 저장할지, 세션의 유효 시간은 얼마인지 등을 결정하는 핵심 역할을 한다. 세션 상태는 기본적으로 인메모리 방식으로 IIS 웹 서버의 프로세스 내에 저장되지만, 이는 웹 팜이나 웹 가든 환경에서는 공유가 불가능해지는 단점이 있다.

이를 해결하기 위해 sessionState의 mode 속성을 변경하여 다른 저장소를 지정할 수 있다. 주요 모드로는 InProc(프로세스 내), StateServer(별도의 상태 서버 프로세스 사용), SQLServer(Microsoft SQL Server 데이터베이스 사용), Custom(사용자 지정 공급자 사용) 등이 있다. StateServer나 SQLServer 모드를 사용하면 여러 웹 서버 인스턴스가 동일한 세션 저장소를 공유할 수 있어 로드 밸런싱 환경에서 사용자 경험을 일관되게 유지하는 데 필수적이다.

구성 예시로, 세션 데이터를 SQL Server에 저장하고 타임아웃 시간을 20분으로 설정하는 경우 다음과 같이 설정할 수 있다. 이때 cookieless 속성을 "true"로 설정하면 URL에 세션 ID를 포함시킬 수 있으나, 보안상 권장되지 않는다.

```xml

<system.web>

<sessionState mode="SQLServer"

sqlConnectionString="데이터 소스=서버이름;초기 카탈로그=데이터베이스이름;"

timeout="20"

cookieless="false" />

</system.web>

```

또한 customProvider를 지정하여 사용자 정의 세션 상태 공급자를 등록하는 것도 가능하다. 세션 상태 관리는 애플리케이션의 확장성과 신뢰성에 직접적인 영향을 미치므로, 배포 환경과 요구사항에 맞는 모드와 설정을 신중하게 선택해야 한다.

web.config 파일의 system.web 섹션 내 customErrors 요소를 사용하면 애플리케이션에서 발생하는 HTTP 오류를 처리하고 사용자에게 친숙한 오류 페이지를 표시할 수 있다. 이 설정은 개발 중인 디버그 환경과 실제 서비스 환경을 구분하여 오류 정보의 노출 수준을 제어하는 데 중요하다. mode 속성을 "On", "Off", "RemoteOnly"로 설정하여 오류 페이지 표시 여부를 결정하며, 일반적으로 서비스 환경에서는 "RemoteOnly"로 설정하여 원격 사용자에게는 사용자 정의 오류 페이지를, 서버에 로컬로 접근하는 개발자에게는 상세 오류 정보를 보여준다.

구체적인 오류 코드별로 다른 페이지를 지정할 수 있다. customErrors 요소 내에 error 요소를 추가하여 특정 HTTP 상태 코드(예: 404, 500)가 발생했을 때 리디렉션할 사용자 정의 페이지의 경로를 설정한다. 이를 통해 "페이지를 찾을 수 없음" 오류 시 맞춤형 404 페이지를 보여주거나, 서버 내부 오류 시 문제 해결을 안내하는 페이지를 제공할 수 있어 사용자 경험을 향상시킨다.

httpErrors 요소를 사용하는 방법도 있다. 이는 IIS 7.0 이상의 통합 파이프라인 모드에서 더욱 정교한 오류 처리를 가능하게 하며, 정적 파일(예: .html)이나 동적 리소스(예: .aspx) 모두를 오류 응답으로 설정할 수 있다. existingResponse 속성을 조정하여 애플리케이션에서 생성된 응답과 IIS의 오류 처리 동작을 통합하는 방식도 제어할 수 있다.

이러한 오류 처리 설정은 애플리케이션의 보안과 유지보수성에도 기여한다. 시스템의 상세 오류 메시지와 스택 추적 정보가 최종 사용자에게 노출되는 것을 방지함으로써 잠재적인 공격 벡터를 줄일 수 있다. 또한, 통일된 오류 페이지를 통해 브랜드 이미지를 유지하고 사용자가 다음에 취할 행동(예: 홈페이지로 돌아가기)을 안내할 수 있다.

web.config 파일의 system.web/compilation 섹션은 ASP.NET 애플리케이션이 동적 컴파일되는 방식을 제어하는 핵심 설정을 담고 있다. 이 섹션에서는 애플리케이션의 코드가 서버에서 어떻게 처리되고 실행될지 정의한다. 주요 설정으로는 대상 프레임워크 버전(targetFramework), 기본 프로그래밍 언어(defaultLanguage), 그리고 임시 파일이 생성될 디렉터리(tempDirectory) 지정 등이 포함된다. 또한, 애플리케이션이 필요로 하는 외부 어셈블리(DLL)를 <assemblies> 하위 요소를 통해 명시적으로 참조할 수 있다.

디버그 설정은 compilation 요소의 debug 속성을 통해 관리된다. 이 속성값을 true로 설정하면 심볼릭 디버그 정보(PDB 파일)가 생성되어 Visual Studio 같은 통합 개발 환경(IDE)에서 상세한 디버깅이 가능해진다. 개발 단계에서는 소스 코드 라인별 실행 추적, 변수 값 확인, 중단점 사용 등이 용이해지므로 문제 해결에 필수적이다. 그러나 이 정보는 애플리케이션 성능에 부정적인 영향을 미칠 수 있으며, 배포된 애플리케이션의 보안을 약화시킬 수도 있다.

따라서, debug="true" 설정은 개발 환경에서만 사용하고, 실제 운영 환경(프로덕션 서버)으로 애플리케이션을 배포할 때는 반드시 debug="false"로 변경해야 하는 것이 보안과 성능 측면에서 권장되는 모범 사례이다. MSBuild나 Azure DevOps와 같은 지속적 통합/지속적 배포(CI/CD) 파이프라인을 사용할 경우, Web.Release.config 같은 구성 파일 변환 기술을 활용해 배포 시 자동으로 디버그 모드를 비활성화하도록 구성할 수 있다. 이는 실수로 인한 설정 누락을 방지하는 데 도움이 된다.

web.config 파일은 마이크로소프트 IIS 웹 서버에서 실행되는 ASP.NET 애플리케이션의 설정을 정의하는 XML 파일이다. 이 파일의 구성 설정은 계층적 구조를 통해 관리되며, 상위 디렉터리의 설정은 하위 디렉터리의 애플리케이션에 상속된다.

가장 상위 수준의 구성 파일은 machine.config 파일이다. 이 파일은 서버의 전역 설정을 담당하며, 서버에 설치된 모든 .NET 프레임워크 애플리케이션에 기본 설정을 제공한다. 그 아래에는 web.config 파일이 위치하며, 이는 루트 웹 사이트 수준, 특정 웹 애플리케이션 수준, 그리고 애플리케이션 내의 개별 하위 디렉터리 수준까지 중첩되어 존재할 수 있다. 특정 애플리케이션 폴더에 web.config 파일이 있으면, 해당 파일의 설정은 상위 디렉터리로부터 상속받은 설정을 재정의하거나 확장한다.

이러한 상속 구조는 설정의 효율적 관리와 유연성을 제공한다. 예를 들어, 서버 전체에 적용될 보안 정책은 machine.config에 정의하고, 특정 웹 애플리케이션만의 데이터베이스 연결 문자열은 해당 애플리케이션 루트의 web.config 파일에 정의할 수 있다. 또한, 특정 하위 폴더에만 다른 인증 규칙을 적용해야 한다면, 그 폴더에 별도의 web.config 파일을 배치하여 상위 설정을 재정의할 수 있다.

이 계층적 구조는 location 요소를 사용하여 더욱 세밀하게 제어될 수 있다. location 요소를 사용하면 단일 web.config 파일 내에서 특정 경로나 파일에만 적용되는 설정을 정의할 수 있어, 물리적으로 여러 개의 구성 파일을 만들지 않고도 설정의 범위를 제한할 수 있다.

location 요소는 웹 애플리케이션 내의 특정 디렉터리나 파일에만 적용되는 구성 설정을 정의하는 데 사용된다. 이는 루트 수준의 web.config 파일에서 설정된 기본 구성을 특정 경로에 대해 재정의하거나 추가할 수 있게 해주는 강력한 기능이다. location 요소의 핵심 속성은 path로, 이 속성에 설정을 적용할 가상 또는 물리적 경로를 지정한다. 이를 통해 관리자는 애플리케이션의 다른 부분에 대해 서로 다른 인증 규칙, 권한 부여 설정, 또는 사용자 정의 오류 페이지를 적용하는 세밀한 제어가 가능해진다.

예를 들어, 웹사이트의 일반 영역은 익명 접근을 허용하지만, /Admin 디렉터리 아래의 관리자 페이지에 대해서는 폼 인증을 강제할 수 있다. 이는 루트 web.config 파일 내에 path="Admin"을 가진 location 섹션을 추가하고, 그 안에 system.web의 authorization 설정을 정의함으로써 구현된다. 마찬가지로, 특정 파일 형식(예: .pdf 파일)이나 특정 리소스에 대한 접근 제어를 설정하는 데에도 활용될 수 있다.

location 요소를 사용할 때 중요한 점은 구성 설정의 상속과 충돌을 이해하는 것이다. IIS는 계층적 구성을 지원하므로, 하위 디렉터리의 web.config 파일은 상위 디렉터리의 설정을 상속받는다. location 요소는 이 상속 체인 내에서 특정 지점에 대한 설정을 명시적으로 지정함으로써, 별도의 하위 구성 파일을 만들지 않고도 중앙 집중식 관리를 가능하게 한다. 또한, inheritInChildApplications 속성을 false로 설정하면, 해당 location 설정이 하위 애플리케이션(가상 디렉터리 등)으로 상속되는 것을 방지할 수 있다.

이 방식의 주요 장점은 구성 관리의 단순화와 유지보수성 향상이다. 여러 관련 설정을 하나의 web.config 파일 내에 통합하여 관리할 수 있으며, 경로 기반으로 설정을 격리시켜 애플리케이션의 다른 부분에 영향을 주지 않고 보안 또는 동작을 조정할 수 있다. 따라서 대규모 또는 복잡한 ASP.NET 웹 애플리케이션을 구성할 때 location 요소는 필수적인 도구가 된다.

Web.config 변환은 ASP.NET 웹 애플리케이션 프로젝트에서 빌드 구성(예: 디버그, 릴리스)에 따라 서로 다른 환경에 맞게 web.config 파일의 설정을 자동으로 수정하는 기능이다. 이 기능은 Visual Studio 2010부터 도입된 웹 게시 파이프라인의 일부로, 주로 개발, 테스트, 운영 환경 간의 구성 차이를 관리하는 데 사용된다. 변환은 별도의 변환 파일(예: Web.Debug.config, Web.Release.config)을 통해 정의되며, 이 파일들은 원본 web.config 파일과 동일한 디렉터리에 위치한다.

변환 파일은 원본 web.config 파일의 복사본이 아니라, 원본 파일에 적용할 변경 지침(XDT 변환 구문)만을 포함하는 XML 파일이다. 변환 작업은 일반적으로 애플리케이션을 특정 구성으로 게시하거나 패키징할 때 수행된다. 예를 들어, Web.Release.config 파일에는 운영 환경에서 데이터베이스 연결 문자열을 변경하거나, 디버그 모드를 비활성화하거나, 사용자 정의 오류 페이지를 설정하는 규칙이 정의될 수 있다.

변환 작업은 TransformXml이라는 MSBuild 작업에 의해 수행된다. 변환 구문은 주로 xdt:Transform 및 xdt:Locator 속성을 사용하여 특정 XML 요소를 찾고 수정하는 방식으로 이루어진다. 일반적인 변환 작업에는 특성 값 치환(SetAttributes), 요소 삽입(Insert), 요소 제거(Remove) 등이 포함된다. 이를 통해 개발자는 환경별로 다른 설정을 소스 코드 내에서 하드코딩하지 않고도 체계적으로 관리할 수 있다.

이 변환 메커니즘은 지속적 통합 및 지속적 배포 파이프라인에서도 활용된다. 빌드 서버는 특정 대상 환경(예: 스테이징, 프로덕션)에 맞는 변환 파일을 선택하여 빌드 아티팩트에 포함된 web.config 파일을 최종적으로 구성한다. 이는 DevOps 관행에서 구성 관리를 자동화하고 환경 간 일관성을 유지하는 데 중요한 역할을 한다.

• Microsoft Learn - ASP.NET Core에서 여러 환경 사용

• Microsoft Learn - ASP.NET Core의 구성

• Microsoft Learn - ASP.NET Core의 앱 설정

• Stack Overflow - How to read appsettings.json values in .NET Core

• Code Maze - ASP.NET Core Configuration – Environment Variables

• Microsoft Learn - 환경 변수 사용

• .NET Blog - Configuration in ASP.NET Core

• C# Corner - Reading Configuration in .NET Core and ASP.NET Core

web.config 파일 내의 연결 문자열이나 인증 키와 같은 민감한 정보는 일반 텍스트로 저장될 경우 보안 위협이 된다. 이러한 정보를 보호하기 위해 ASP.NET은 구성 섹션을 암호화하는 기능을 제공한다. 주로 aspnet_regiis.exe 명령줄 도구를 사용하거나 프로그래밍 방식으로 구성 섹션을 암호화 및 복호화할 수 있다.

주요 암호화 방식은 RSA (Rivest-Shamir-Adleman) 알고리즘을 이용한 공급자 기반 암호화와 DPAPI (데이터 보호 API)를 이용하는 방법이 있다. RSA 방식은 키 쌍을 생성하고 관리해야 하므로 여러 서버 간 구성 파일을 공유하는 웹 팜 환경에 적합하다. 반면, DPAPI 방식은 로컬 컴퓨터 계정이나 사용자 계정 수준에서 암호화하므로 단일 서버 환경에서 사용하기 더 간편하다.

암호화는 일반적으로 connectionStrings나 appSettings와 같은 특정 구성 섹션에 적용된다. 암호화된 섹션은 web.config 파일 내에서 읽을 수 없는 암호문 형태로 저장되지만, 애플리케이션은 런타임에 자동으로 복호화된 값을 읽어 사용한다. 이는 애플리케이션 코드를 변경할 필요 없이 보안을 강화할 수 있는 장점이 있다.

암호화된 구성 파일을 관리할 때는 암호화에 사용된 키의 백업과 보안이 중요하다. 키를 분실하면 구성 정보를 복원할 수 없으며, 키가 유출되면 보호의 의미가 퇴색된다. 또한, 소스 코드 관리 시스템에 암호화된 설정 파일을 커밋할 때는 해당 환경에서만 유효한 키를 사용했는지 주의해야 한다.

web.config 파일은 애플리케이션의 핵심 설정을 담고 있으므로, 불필요한 정보가 외부에 노출되지 않도록 주의해야 한다. 기본적으로 IIS는 .config 확장자를 가진 파일에 대한 직접적인 HTTP 요청을 차단하지만, 구성 오류나 서버 설정에 따라 민감한 정보가 유출될 수 있다.

가장 중요한 보안 조치는 연결 문자열이나 API 키와 같은 민감한 설정 값을 평문으로 저장하지 않는 것이다. 이러한 정보는 connectionStrings나 appSettings 섹션에 직접 노출시키기보다, ASP.NET에서 제공하는 aspnet_regiis 도구를 이용한 구성 섹션 암호화 기능을 사용하거나, Windows의 DPAPI 또는 외부 키 관리 서비스를 활용하여 암호화해야 한다. 또한, 개발 중 사용한 디버그 설정이나 상세한 오류 메시지가 프로덕션 환경에 그대로 노출되지 않도록 compilation debug="false" 및 customErrors 모드를 적절히 설정해야 한다.

파일 자체의 접근을 제한하는 것도 중요하다. IIS의 요청 필터링 규칙을 통해 .config 파일에 대한 접근을 차단해야 하며, 필요하지 않은 구성 섹션은 제거하는 것이 좋다. 예를 들어, 애플리케이션에서 사용하지 않는 인증 모듈에 대한 설정이나 상세한 추적 정보를 출력하는 trace 섹션 등은 제거함으로써 공격자가 애플리케이션 구조를 파악하는 데 이용할 수 있는 정보를 최소화할 수 있다.

정기적인 보안 감사와 함께, 소스 코드 관리 시스템에는 민감 정보가 제거된 템플릿 web.config 파일만 커밋하고, 실제 배포 시에는 환경별 변환 도구나 외부 구성 관리 시스템을 통해 안전하게 값을 주입하는 방식을 채택하는 것이 현대적인 보안 모범 사례이다.