Почему общедоступный статический заключительный массив является дырой в системе безопасности?

Внешний класс может изменять содержимое массива, что, вероятно, не является тем, что вы хотите, чтобы пользователи вашего класса делали (вы хотите, чтобы они делали это через метод). Похоже, автор имел в виду, что это нарушает инкапсуляцию, а не безопасность.

Я предполагаю, что кто-то, объявляющий эту строку, мог подумать, что другие классы не могут изменять содержимое массива, так как он помечен как final, но это не так, final только останавливает вас от переназначения атрибута.

В этом объявлении клиент может изменять Thing [0], Thing [1] и т. Д. (Т. Е. Элементы в массиве).

Чтобы понять, почему это потенциальная дыра в безопасности, а не просто плохая инкапсуляция, рассмотрим следующий пример:

public class SafeSites {
    // a trusted class with permission to create network connections
    public static final String[] ALLOWED_URLS = new String[] {
        "http://amazon.com", "http://cnn.com"};

    // this method allows untrusted code to connect to allowed sites (only)
    public static void doRequest(String url) {
        for (String allowed : ALLOWED_URLS) {
            if (url.equals(allowed)) {
                 // send a request ...
            }
        }
    }
}

public class Untrusted {
     // An untrusted class that is executed in a security sandbox.

     public void naughtyBoy() {
         SafeSites.ALLOWED_URLS[0] = "http://myporn.com";
         SafeSites.doRequest("http://myporn.com");
     }
}

Как видите, ошибочное использование последнего массива означает, что ненадежный код может нарушить ограничение, что доверенный код / sandbox пытается навязать. В данном случае это явно проблема безопасности.

Если ваш код не является частью критически важного для безопасности приложения, вы можете игнорировать эту проблему. Но ИМО, это плохая идея. В какой-то момент в будущем вы (или кто-то другой) можете повторно использовать свой код в контексте, где безопасность является проблемой. Во всяком случае, именно автор называет публичные финальные массивы проблемой безопасности.

Эмбер сказала это в комментарии:

Нет большей дыры в безопасности, чем частный, если бы вы могли читать исходный код и / или байт-код в любом случае ...

Это неверно.

Тот факт, что «плохой парень» может использовать исходный код / ​​байт-коды, чтобы определить, что частный существует и ссылается на массив, недостаточен для нарушения безопасности. Плохой парень также должен внедрить код в JVM, у которого есть необходимые разрешения для использования отражения. Это разрешение недоступно для ненадежного кода, работающего в (правильно реализованной) изолированной программной среде безопасности.

Обратите внимание, что массив ненулевой длины всегда изменяем, поэтому неправильно для класса иметь публичное статическое конечное поле массива или аксессор, возвращающий такое поле. Если класс имеет такое поле или аксессор, клиенты смогут изменять содержимое массива.

-- Эффективная Java, 2-е изд. (стр. 70)

Думаю, это просто означает всю эту историю с public vs private. Предполагается, что хорошей практикой является объявление локальных переменных приватными, а затем использование методов get и set, а не прямой доступ к ним. Это немного усложняет работу с ними вне вашей программы. Это все, насколько я знаю.

Потому что ключевое слово final гарантирует только значение ссылки (например, как место в памяти), но не содержимое в ней.