En los cursos de programación de OO, los maestros siempre nos dicen que configuremos a los miembros de la clase para que sean privados, a menos que haya una buena razón porque es más "seguro".
¿De qué manera la configuración de los miembros en privado hace que el programa sea más seguro? ¿Cuáles son las amenazas potenciales para hacer públicos a los miembros de la clase?
En realidad, poner a un miembro de la clase en público o privado no tiene nada que ver con la seguridad. Esta respuesta en stackoverflow lo cubre bastante bien:
¿Qué son públicos, privados y protegidos en un objeto? programación orientada?
También tenga en cuenta que hay lenguajes como Python donde solo hay una convención para iniciar métodos privados con un guión bajo. Sin embargo, todos los programadores pueden acceder a este método desde otra clase. Esta pregunta de Stackoverflow cubre esto bastante bien: ¿Por qué no son los métodos privados de Python en realidad privado?
Hay situaciones limitadas y específicas en las que la visibilidad de campo tiene un impacto. Estoy hablando de applets de Java . Un applet de Java sin firma solo puede realizar interacciones limitadas del sistema (no hay acceso a archivos locales, no hay conexión a servidores externos, excepto el que sirvió al código del applet, etc.). Estas restricciones se aplican a través de un marco complejo de "permisos" que se implementa ... en el código Java de la biblioteca estándar.
Si un applet podría acceder a campos privados de objetos Java arbitrarios desde otros paquetes, entonces podría jugar con los objetos y tablas que definen los permisos actuales para el propio applet. En efecto, el derecho a utilizar la reflexión API en todas las clases (incluidas las clases del sistema) técnicamente otorga Todos los derechos sobre el applet.
Esto no significa que las palabras clave de visibilidad de campo como private o protected sean una característica de seguridad; significa que los diseñadores de Sun / Oracle usaron la visibilidad de campo para implementar y respaldar un marco de seguridad (y, en mi opinión, deberían haberlo hecho de otra manera, porque hacerlo de esa manera es como tratar de mantener una lista negra de "llamadas peligrosas" "en miles de posibles llamadas, y es un trabajo muy duro, y la aparición recurrente de las vulnerabilidades de 0 días de Java es un testimonio de la dureza de tal enfoque).
Para la mayoría de las demás situaciones, los campos de objetos deben hacerse privados porque promueve mejores prácticas de ingeniería de software, lo que hace que el código sea más fácil de mantener (como todas las reglas, que hay excepciones; ocasionalmente , una campo público es una mejor idea). No hay nada acerca de seguridad aquí; se trata de usabilidad y mantenibilidad .
Si declaramos que los miembros de la clase son privados, solo se puede acceder dentro de la clase. Entonces, si observamos el punto de vista de la seguridad, declararlo como privado protege a los miembros de la clase.
No se puede acceder a los métodos de miembro utilizando los objetos si se declaran como privados.
No se puede acceder a las variables miembro si son privadas.
Por lo tanto, en los programas, si tiene que mantener algunos valores como secretos, como las claves de cifrado, otras credenciales, debe declararse como privado. En algunos casos, si está escribiendo un método para la autenticación, hacerlos privados aumentará un poco el nivel de seguridad.
Lea otras preguntas en las etiquetas attack-prevention java programming .net