Código abierto de la base de datos

Esta es una buena pregunta con una respuesta simple:

  

Las mejores prácticas no se pueden aplicar en todas las situaciones.

Las mejores prácticas de "no le digas al mundo qué algoritmos de seguridad usas" y también "no expongas tu estructura de base de datos" existen como un posible respaldo, en caso de que tu código tenga un error de seguridad, es mucho más difícil para alguien explotarlo si no saben cómo funciona detrás de escena. Obviamente, estas dos mejores prácticas entran en conflicto directamente con el Código Abierto, por lo que, en primer lugar, debes concentrarte en no tener fallas de seguridad. Afortunadamente, abrir tu código fuente te ayudará con eso.

Confiar en mantener el secreto de su esquema para proteger su sistema no es un buen punto de partida. No es el principio de Kerchoff, pero si la seguridad de su sistema se basa en la oscuridad del esquema, entonces incluso si lo mantiene cerrado y no lo ofrece a nadie más, tiene problemas.

  

el script con el nombre de usuario / contraseña de conexión no debe estar alojado en el repositorio de origen

No.

Ciertamente, no desea poner sus credenciales de base de datos en un repositorio público, pero debería poner el código para administrarlas y aplicarlas en el informe. Puede usar valores ficticios en el repositorio, leerlos desde un archivo plano o env, usar los valores predeterminados en PHP.ini, usar las credenciales proporcionadas por el usuario almacenadas en la sesión, restringir el acceso a localhost y no requerir una contraseña ... .Hay potencialmente muchas soluciones.

  

Sin embargo, no estoy seguro de cómo proceder, ya que también he oído que lo haces.   No quiero exponer su estructura de base de datos a otros.

No desea exponerlos porque, si existe una inyección de SQL, ellos saben qué tablas apuntar. Sin embargo, si existe la inyección SQL para que esto suceda, es una protección discutible ya que su seguridad ya está dañada. Especialmente debido a que la mayoría de las aplicaciones PHP / SQL en la naturaleza rara vez configuran los permisos de usuario de SQL adecuados. Así que la mayoría de las veces el atacante puede hacer un volcado de su estructura y no tiene necesidad de adivinarlo.

  

Lo único de lo que estoy seguro es que el script con la conexión   El nombre de usuario / contraseña no debe estar alojado en el repositorio de origen de mi   elección.

Muchos proyectos evitan esto al proporcionar una configuración de muestra y luego, a través de su software de control de versiones, crean una regla que evita que su configuración se transfiera al repositorio de control de versiones. Un ejemplo de esto es que pueden tener una configuración de ejemplo llamada config-EXAMPLE.php y su secuencia de comandos de configuración cambia su nombre a config.php (o crea desde cero) tan pronto como la información esté disponible. Y si están utilizando Github, por ejemplo, incluyen una regla .gitignore para bloquear config.php, lo que garantizará que no lo hagan. No exponga accidentalmente su propia configuración.

  

Actualmente no es de código abierto, pero estoy considerando abrirlo   fuente, para que otros puedan corregir errores, mejorarlo ...

No olvide la seguridad al hacer esta declaración. Lo mejor del código abierto es que otros pueden detectar lo que usted no hace y corregirlo o mejorarlo. Y esto incluye la seguridad. La fuente abierta de su proyecto podría potencialmente solucionar más problemas de seguridad de los que expone.