<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="anyRoot">
    <xs:complexType>
      <xs:sequence>
        <xs:any minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
      </xs:sequence>
      <xs:anyAttribute processContents="lax"/>
    </xs:complexType>
  </xs:element>
</xs:schema>

import javax.xml.parsers.DocumentBuilderFactory;
import org.w3c.dom.Document;
import java.io.File;

public class XmlValidator {
    public void parseXmlWithUniversalSchema(File xmlFile) throws Exception {
        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
        
        // 1. 네임스페이스 및 검증 모드 활성화 (CWE-112 대응 기본)
        factory.setNamespaceAware(true);
        factory.setValidating(true);
        
        // 2. XXE 공격 방어 설정 (CWE-611 대응)
        factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
        factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
        factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
        
        // 3. JAXP 스키마 소스 설정 (무적의 스키마 연결)
        factory.setAttribute("http://java.sun.com/xml/jaxp/properties/schemaLanguage", 
                             "http://www.w3.org/2001/XMLSchema");
        factory.setAttribute("http://java.sun.com/xml/jaxp/properties/schemaSource", 
                             new File("path/to/universal.xsd"));
        
        // 4. 파싱 수행
        Document doc = factory.newDocumentBuilder().parse(xmlFile);
        System.out.println("XML 검증 및 파싱 완료: " + doc.getDocumentElement().getNodeName());
    }
}

 

 

 

XSD(XML Schema Definition)는 W3C(World Wide Web Consortium)에 의해 권고안(Recommendation)으로 공식 발표되었습니다.

1. 공식 출시일

• 2001년 5월 2일

이날 W3C는 XML Schema Part 0, 1, 2를 동시에 발표하며 XML 문서의 구조를 정의하는 표준 규격으로 확정했습니다.

---

2. XSD의 역사적 배경과 버전

XSD는 기존에 사용되던 DTD(Document Type Definition)의 한계를 극복하기 위해 탄생했습니다. DTD는 XML 문법이 아닌 독자적인 문법을 사용했고, 숫자나 날짜 같은 세밀한 데이터 타입을 정의할 수 없다는 단점이 있었기 때문입니다.

• v1.0 (2001년 5월): 최초의 공식 권고안입니다.

• v1.1 (2012년 4월): 약 11년 만에 업데이트된 버전으로, 조건부 유효성 검사(Assertions) 등 더욱 강력한 기능이 추가되었습니다.

---

3. 왜 보안(CWE-112)에서 중요할까?

2001년 XSD가 출시된 이후, 웹 애플리케이션은 비로소 강력한 데이터 타입 검증이 가능해졌습니다.

• CWE-112 대응: 단순한 텍스트 비교가 아니라, XSD를 통해 "이 필드에는 반드시 8자리 숫자만 들어와야 한다"는 식의 엄격한 규칙을 적용함으로써, XML 주입(Injection)이나 잘못된 요소 조합을 통한 공격을 원천적으로 차단할 수 있게 된 것입니다.

 

 

 

사업의 성격과 계약 조건에 따라 다르겠지만, 결론부터 말씀드리면 "보안 가이드라인 준수"가 과업 지시서에 포함되어 있다면 사업 범위에 포함되는 것이 일반적입니다.

특히 최근 공공기관이나 금융권 프로젝트라면, 기능 개선뿐만 아니라 '시큐어 코딩(Secure Coding)' 적용이 필수 조건으로 붙는 경우가 많기 때문입니다. 

---

1. 사업 범위에 포함된다고 보는 이유 (보안성 강화)

기존에 검증이 없었더라도 다음 조건 중 하나라도 해당한다면 개발 범위에 포함됩니다.

• 시큐어 코딩 의무화: 과업 지시서나 계약서에 "KISA 소프트웨어 보안 약점 진단 가이드 준수" 또는 "CWE/SANS 25 준수" 문구가 있다면, CWE-112(불충분한 유효성 검사) 해결을 위해 XSD 검증을 넣는 것은 개발자의 의무입니다.

• 취약점 점검 조치: 사업 종료 전 보안 점검(Pen-Test)을 받게 될 텐데, 여기서 XML 관련 취약점이 지적되면 어차피 수정해야 하는 사항입니다.

• 데이터 정합성 보장: 기능 개선의 목적이 '시스템 안정성'이라면, 비정상 데이터를 입구에서 컷(Cut)하는 검증 로직 추가는 기능 구현의 일부로 간주됩니다.

2. 사업 범위 밖이라고 주장할 수 있는 경우

반대로 다음과 같은 상황이라면 별도의 '추가 과업'으로 협상이 가능할 수 있습니다.

• 단순 UI/UX 개선: 백엔드 로직이나 데이터 구조를 전혀 건드리지 않는 단순 화면 개선 사업인 경우.

• 상위 기관의 XSD 미제공: 상위 기관에서 규격만 문서로 주고 실제 XSD 파일을 주지 않아, 이를 새로 설계해야 하는 공수가 큰 경우. (이 경우 설계 비용 청구 가능)

• 유지보수 성격의 소규모 사업: 신규 기능 추가 없이 기존 로직을 '유지'만 하는 계약인 경우.

구분	수행사(개발팀) 책임	발주처(상위기관) 책임
XSD 파일	제공된 XSD를 시스템에 연동 및 적용	표준 XSD 설계 및 최신본 제공
보안 설정	파서에 setFeature 등 보안 옵션 적용	보안 가이드라인 기준 제시
에러 처리	검증 실패 시 로그 기록 및 응답 처리	검증 실패 시 업무 프로세스 가이드 제공