Apex Academy
Módulo 12·Checkpoint·45 min

Checkpoint del Módulo 12

La entrega, y la última del curso: la clase que usa la pantalla de renovaciones tiene los cuatro hallazgos de la auditoría a la vez. La dejas con el sharing declarado, sin inyección, sin enseñar el margen a quien no debe y guardando con los permisos del usuario.

En Admin esPasar el Health Check de Setup, pero sobre tu propio código

✓ En esta sub-lección

  1. 01Auditar una clase y reconocer sus fallos de seguridad.
  2. 02Elegir para cada fallo la herramienta del módulo que lo cierra.
  3. 03Dejar una clase que un auditor aprobaría.

La nutria: ¿Te acuerdas? · Repaso de la lección 5

¿Qué hace System.runAs(intern) { … } en un test?

Hasta ahora cada hallazgo venía solo y con su nombre. En el trabajo real no: te llega una clase de veinte líneas y nadie te dice qué tiene. La pantalla de renovaciones usa RenewalDeskController, que busca renovaciones por nombre de cuenta y las cierra como ganadas. El auditor ha contado cuatro hallazgos en ella.

Las cuatro preguntas del auditor

PreguntaSi la respuesta es noTarea
¿La clase declara su sharing?with sharing, salvo razón escrita para otra cosa.1
¿Lo que escribe el usuario viaja como valor?Consulta entre corchetes con :variable, o queryWithBinds.4
¿Lo que se muestra respeta los permisos de campo?Security.stripInaccessible antes de devolverlo.2 y 3
¿Lo que se guarda respeta los permisos del usuario?WITH USER_MODE y «as user».3

RenewalDeskController

  • abierto

    El comercial ve renovaciones de cuentas que no son suyas.

  • abierto

    Una comilla en la búsqueda cambia la consulta.

  • abierto

    El margen llega a quien lo tiene oculto.

  • abierto

    Un usuario de solo lectura puede cerrar una oportunidad.

Informe del auditor:Hallazgos abiertos: 4

Activa cada arreglo. Fíjate en que cerrar uno no cierra los demás.

Activa cada arreglo y vuelve a pasar la auditoría: mira qué hallazgos quedan abiertos y qué ve el comercial en cada caso.

Fíjate en que las cuatro son independientes. with sharing decide qué registros se ven, pero no qué campos. El modo usuario aplica permisos, pero no impide una inyección. Enlazar valores impide la inyección, pero no sabe nada de permisos. Una clase segura contesta sí a las cuatro, y ninguna tapa a otra.

La nutria: ¿Y por qué no un Flow? La última vez que te lo pregunto

En seguridad, Flow te lo da más hecho: un desplegable decide el contexto de todo el flow, y un Get Records no se puede inyectar. Apex te deja decidir operación por operación, y a cambio cada decisión es tuya y cada olvido también. Por eso, después de doce módulos, la pregunta sigue siendo la primera que debes hacerte: si un flow lo resuelve bien, es el flow. Y cuando no llega, por volumen, por lógica, por integración o por control fino, ahora sabes escribir el código, y escribirlo de forma que un auditor lo apruebe.

Lo que viene: el Desafío 2

Con esta entrega terminas los doce módulos, y se desbloquea el Desafío 2, el proyecto final: un caso completo sin tareas guiadas, donde tú decides qué va en un flow, qué va en Apex y cómo lo pruebas y lo aseguras.