La seguridad en una aplicación web no es un detalle opcional, es una capa que defines desde el backend. Cuando trabajas con políticas de autorización en Laravel, controlas que cada usuario solo pueda editar lo que le pertenece, en este caso sus propias preguntas dentro de un foro.

¿Por qué necesitas una política para editar preguntas?

Sin una política activa, cualquier usuario autenticado puede editar cualquier pregunta del sistema. Eso rompe la lógica de propiedad y abre la puerta a manipulaciones indebidas.

La misma regla que ya aplicaste para las respuestas se replica aquí: si la pregunta no es tuya, no deberías ni siquiera ver el formulario de edición. Esa coherencia entre entidades es lo que mantiene tu aplicación predecible y segura.

¿Qué es una policy en Laravel? Es una clase que agrupa la lógica de autorización de un modelo. Define quién puede ver, crear, actualizar o eliminar un recurso específico comparando el usuario autenticado con la entidad.

¿Cómo se genera una nueva policy con Artisan?

Todo arranca desde la terminal con el comando de scaffolding que Laravel ofrece para este tipo de archivos.

bash php artisan make:policy QuestionPolicy

Esto crea un archivo dentro de app/Policies con los métodos base. El que te interesa es update, donde defines la regla: el id del usuario autenticado debe coincidir con el user_id de la pregunta.

La lógica reutiliza el mismo patrón que ya escribiste para respuestas, así que puedes copiar el método, pegarlo en la nueva policy y ajustar la entidad de referencia. Recuerda algo central: una policy siempre evalúa un usuario respecto a otra entidad.

¿Qué hace el método update dentro de la policy?

Este método recibe el usuario y la pregunta, y devuelve true o false. Si devuelve true, el usuario puede continuar; si devuelve false, Laravel bloquea la acción automáticamente.

No necesitas escribir condicionales largos en el controlador. La policy concentra esa decisión en un solo lugar.

¿Cómo aplicar la autorización en el controlador?

Dentro del controlador de preguntas, en los métodos edit y update, llamas al helper de autorización pasando la acción y la entidad.

php $this->authorize('update', $question);

Con esa línea bloqueas dos puntos críticos:

• El acceso al formulario de edición.
• El envío del formulario para actualizar.

Si un usuario intenta editar una pregunta ajena, Laravel responde con un mensaje de No estás autorizado, sin que tengas que construir esa validación a mano.

¿Dónde debe vivir la autorización, en el frontend o en el backend? Siempre en el backend primero. El frontend solo refleja lo que el servidor ya validó. Ocultar un botón sin proteger la ruta deja la puerta abierta.

¿Cómo ocultar el botón Editar con la directiva Can en Blade?

Una vez que el backend está blindado, puedes pulir la experiencia visual. Laravel ofrece la directiva @can para mostrar u ocultar elementos según los permisos del usuario.

blade @can('update', $question) <a href="...">Editar</a> @endcan

El resultado se actualiza automáticamente: el botón Editar desaparece en las preguntas que no te pertenecen y permanece visible en las tuyas. La interfaz se vuelve consistente con la regla de negocio.

¿Por qué validar siempre primero en el backend?

Porque cualquier persona puede manipular el HTML o disparar peticiones directas a tus rutas. Si tu única defensa es esconder un botón, basta con conocer la URL para saltarse la restricción.

La secuencia correcta es: primero la policy y la llamada a authorize en el controlador, después la directiva @can en la vista. En ese orden, tu aplicación queda protegida en ambos frentes.

Con esta política activa, cada usuario edita únicamente sus propias preguntas, igual que ocurre con las respuestas. ¿Cómo aplicarías esta misma lógica para permitir eliminar preguntas? Cuéntame en los comentarios cómo lo resolverías.