The following items are things to consider when working with the XmlReader class.

• Exceptions thrown the XmlReader can disclose path information that you do not want bubbled up to the application. Your applications must catch exceptions and process them appropriately.

• Do not enable DTD processing if you are concerned about denial of service issues or if you are dealing with untrusted sources. DTD processing is disabled by default for XmlReader objects created by the Create method.

  If you have DTD processing enabled, you can use the XmlSecureResolver to restrict the resources that the XmlReader can access. You can also design your application so that the XML processing is memory and time constrained. For example, configure time-out limits in your ASP.NET application.

• XML data can include references to external resources such as a schema file. By default external resources are resolved using an XmlUrlResolver object with no user credentials. You can secure this further by doing one of the following:

  • Restrict the resources that the XmlReader can access by setting the XmlReaderSettings..::.XmlResolver property to an XmlSecureResolver object.

  • Do not allow the XmlReader to open any external resources by setting the XmlReaderSettings..::.XmlResolver property to nullNothingnullptra null reference (Nothing in Visual Basic).

• XML data can contain a large number of attributes, namespace declarations, nested elements and so on that require a substantial amount of time to process. To limit the size of the input that is sent to the XmlReader, create a custom IStream implementation and supply it the XmlReader.

• The ReadValueChunk method can be used to handle large streams of data. This method reads a small number of characters at a time instead of allocating a single string for the whole value.

• When reading an XML document with a large number of unique local names, namespaces, or prefixes, a problem can occur. If you are using class that derives from XmlReader, and you call either the LocalName, Prefix, or NamespaceURI property for each item, the returned string is added to a NameTable. The collection held by the NameTable never decreases in size, creating a virtual "memory leak" of the string handles. One mitigation for this is to derive from the NameTable class and enforce a maximum size quota. (There is no way to prevent the use of a NameTable, or to switch the NameTable when it is full). Another mitigation is to avoid using the properties mentioned and instead use the MoveToAttribute method with the IsStartElement method where possible; those methods do not return strings and thus avoid the problem of overfilling the NameTable collection.