Защита ресурсов HTTP

Когда URI запроса соответствует нескольким защищённым шаблонам URL, к запросу применяются те ограничения, которые связаны с шаблоном URL с наилучшим соответствием. Правила соответствия сервлетов, определённые в главе 12 «Отображение запросов в сервлеты» в Спецификации Java Servlet 4.0, используются для определения наиболее подходящего шаблона URL для URI запроса. Никакие требования защиты не применяются к URI запроса, который не соответствует какому-либо защищённому шаблону URL. Метод HTTP запроса не играет роли в выборе наиболее подходящего шаблона URL для запроса.

Когда методы HTTP перечислены в определении ограничения, средства защиты, определённые этим ограничением, применяются только к перечисленным методам.

Когда методы HTTP не перечислены в определении ограничения, средства защиты, определённые этим ограничением, применяются ко всему набору методов HTTP, включая методы расширения HTTP.

Когда ограничения с различными требованиями защиты применяются к одной и той же комбинации шаблонов URL и методов HTTP, правила объединения требований защиты определены в Разделе 13.8.1, «Объединение ограничений» в Спецификации Java-сервлета 4.0.

Следуйте этим рекомендациям, чтобы правильно защитить веб-приложение.

Не перечисляйте методы HTTP в определениях ограничений. Это самый простой способ убедиться, что вы не оставляете методы HTTP незащищёнными. Например:
```

<security-constraint>
    <display-name>Do not enumerate Http Methods</display-name>
    <web-resource-collection>
        <url-pattern>/company/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>sales</role-name>
    </auth-constraint>
</security-constraint>
```
Если вы перечислите методы в ограничении, все не перечисленные методы из фактически бесконечного набора возможных методов HTTP, включая методы расширения, будут не защищены. Используйте такое ограничение, только если вы уверены, что это схема защиты, которую вы намереваетесь определить. В следующем примере показано ограничение, которое указывает метод GET и, таким образом, оставляет незащищёнными все остальные HTTP методы:
```

<security-constraint>
    <display-name>
        Protect GET only, leave all other methods unprotected
    </display-name>
    <web-resource-collection>
        <url-pattern>/company/*</url-pattern>
        <http-method>GET</http-method>
    </web-resource-collection>
    <auth-constraint>
        <role-name>sales</role-name>
    </auth-constraint>
</security-constraint>
```
Если требуется применить определённые типы защиты к определённым HTTP методам, убедитесь, что вы задаёте ограничения, чтобы охватить каждый метод, который вы хотите разрешить, с или без ограничения, для соответствующих шаблонов URL. Если есть какие-либо методы, которые вы не хотите разрешать, вы также должны создать ограничение, которое запрещает доступ к этим методам по тем же шаблонам. Как пример см. ограничение безопасности № 5 в следующем пункте.

Например, чтобы разрешить GET и POST, когда POST требует аутентификации, а GET разрешён без ограничений, вы можете определить следующие ограничения:
```

<security-constraint>
    <display-name>Allow unprotected GET</display-name>
    <web-resource-collection>
        <url-pattern>/company/*</url-pattern>
        <http-method>GET</http-method>
    </web-resource-collection>
</security-constraint>


<security-constraint>
    <display-name>Require authentication for POST</display-name>
    <web-resource-collection>
        <url-pattern>/company/*</url-pattern>
        <http-method>POST</http-method>
    </web-resource-collection>
    <auth-constraint>
        <role-name>sales</role-name>
    </auth-constraint>
</security-constraint>
```
Самый простой способ убедиться, что вы запрещаете все HTTP методы, кроме тех, которые вы хотите разрешить, — это использовать элементы http-method-omission, чтобы исключить эти HTTP методы из ограничения безопасности, а также определить auth-constraint, который не называет роли. Ограничение безопасности будет применяться ко всем методам, кроме тех, которые были названы в пропусках, и ограничение будет применяться только к ресурсам, соответствующим шаблонам в ограничении.

Например, следующее ограничение исключает доступ ко всем методам, кроме GET и POST, для ресурсов, соответствующих шаблону /company/*:
```

<security-constraint>
    <display-name>Deny all HTTP methods except GET and POST</display-name>
    <web-resource-collection>
        <url-pattern>/company/*</url-pattern>
        <http-method-omission>GET</http-method-omission>
        <http-method-omission>POST</http-method-omission>
    </web-resource-collection>
    <auth-constraint/>
</security-constraint>
```
Если вы хотите распространить эти исключения на свободные части вашего приложения, также включите шаблон URL / (косая черта):
```

<security-constraint>
    <display-name>Deny all HTTP methods except GET and POST</display-name>
    <web-resource-collection>
        <url-pattern>/company/*</url-pattern>
        <url-pattern>/</url-pattern>
        <http-method-omission>GET</http-method-omission>
        <http-method-omission>POST</http-method-omission>
    </web-resource-collection>
    <auth-constraint/>
</security-constraint>
```
Если вы не хотите, чтобы какой-либо ресурс вашего веб-приложения был доступен, пока вы явно не определите ограничение, разрешающее доступ к нему, вы можете определить элемент auth-constraint, который не указывает роли и связывает его с шаблоном URL /. Шаблон URL / — самый слабый подходящий шаблон. Не перечисляйте никакие методы HTTP в этом ограничении:
```

<security-constraint>
    <display-name>
        Switch from Constraint to Permission model
        (where everything is denied by default)
    </display-name>
    <web-resource-collection>
        <url-pattern>/</url-pattern>
    </web-resource-collection>
    <auth-constraint/>
</security-constraint>
```