Busca en todas las páginas de la documentación
La seguridad de los programas de Solana es seguridad de cuentas. Los llamadores eligen qué cuentas y programas entran en una instrucción; Sealevel aplica bloqueos, reglas de escritura de propiedad y presupuestos de cómputo, no el saldo de tu bóveda, la lista de administradores o la vinculación de la menta.
Esta página es el mapa conceptual para Seguridad y Auditoría de Programas: superficie de ataque de Sealevel, validación de cuentas, comprobaciones de firmante y propietario, ataques de PDA y semillas, reinicialización, aritmética, riesgo de CPI y reentrada, y un flujo de trabajo de auditoría práctico en Agave 4.1.1.
#[derive(Accounts)], prepararse para auditoría externa, triaje de hallazgos o enseñar el modelo de amenazas de Solana.UncheckedAccount y remaining_accounts reintroducen riesgo; las revisiones de seguridad no reemplazan el fuzzing o la revisión de diseño económico.Sealevel ejecuta programas como ejecutables sin estado. El estado duradero vive en cuentas que la transacción lista por adelantado. Los clientes (o atacantes) suministran esas cuentas, indicadores de firmante y indicadores de escritura. El runtime verifica que los firmantes declarados realmente firmaron y que solo el programa propietario puede escribir datos de cuenta. No sabe que "esta TokenAccount debe coincidir con vault.mint" o "solo la autoridad puede retirar".
Esa brecha es la superficie de ataque:
El cliente / atacante suministra:
program_id | datos de instrucción | AccountMeta[] (claves, is_signer, is_writable)
El runtime garantiza:
firmas coinciden con is_signer | bloqueos de is_writable | reglas de escritura del propietario | presupuesto de CU
Tu programa debe garantizar:
identidad correcta firmada | propietarios y tipos correctos | PDAs correctos | montos correctos | CPIs segurasFallar cerrado es la postura predeterminada: si la validación está incompleta, rechaza con un error tipificado. Nunca asumas "clientes honestos" o "nuestro frontend solo crea buenas transacciones". Los frontends y los indexadores no forman parte del límite de confianza; las comprobaciones en cadena sí lo son.
Anchor 0.32.1 codifica comprobaciones comunes (Signer, Account<T>, semillas, has_one, Program<T>). Eso no es una revisión completa. Aparecen lagunas con AccountInfo, UncheckedAccount, remaining_accounts, init_if_needed sin protección y las restricciones de reglas de negocio no se pueden expresar.
Modelo de amenazas para un programa típico de bóveda o mercado:
| Activo en riesgo | Fallo típico | Control de primera línea |
|---|---|---|
| Tokens / lamports | Firmante faltante o cuenta de token incorrecta | Signer, restricciones de menta/propietario |
| Autoridad de administrador / configuración | Reinicio o has_one no establecido | Inicialización única, autoridad almacenada + firmante |
| Contabilidad del protocolo | Desbordamiento, redondeo incorrecto | checked_*, intermedios u128 |
| Componibilidad | CPI a programa impostor | Lista blanca de ID de programa, CEI |
| Identidad del estado | PDA o confusión de tipos incorrectos | semillas + bump, discriminadores |
Los atacantes pasan cuentas que parecen utilizables: mismo tamaño, propiedad de tu programa o deserializables en el tipo incorrecto. La validación significa más que "se deserializa".
Lista de verificación por rol de cuenta:
Account<T> para tus tipos; require_keys_eq! para SPL Token, Sysvar, etc.).mut.seeds + bump almacenado para que la dirección se derive, no se elija libremente.#[derive(Accounts)]
pub struct Deposit<'info> {
// `has_one = mint` requeriría un campo de cuenta `mint` en esta estructura; la
// restricción explícita de menta a continuación cubre el enlace sin uno.
#[account(mut, has_one = authority)]
pub vault: Account<'info, Vault>,
#[account(
mut,
constraint = user_ata.mint == vault.mint @ ErrorCode::MintMismatch,
constraint = user_ata.owner == user.key() @ ErrorCode::WrongAtaOwner,
)]
pub user_ata: Account<'info, TokenAccount>,
pub authority: Signer<'info>,
pub user: Signer<'info>,
pub token_program: Program<'info, Token>,
}UncheckedAccount y AccountInfo en bruto omiten las comprobaciones de propietario y disco hasta que las agregues. Trata cada campo de este tipo como un hallazgo hasta que se demuestre que está validado.
Firmante: cualquier ruta que mueva fondos, cambie la autoridad, cierre cuentas o actualice la configuración sensible necesita una firma criptográfica de la clave correcta (o un PDA firmado a través de invoke_signed con semillas controladas por el programa).
Propietario: solo el programa propietario puede reescribir datos. Leer una cuenta que tu programa no posee sin verificar el propietario es cómo entran la confusión de tipos y las mentas falsas. Para las cuentas de tokens, el propietario debe ser el programa Token o Token-2022 que pretendes; para tu estado, el propietario debe ser tu program_id.
Patrón crítico común: la bóveda almacena authority: Pubkey pero la instrucción nunca requiere authority como Signer o nunca la vincula con has_one.
Los PDAs son identidad de autoridad y dirección. Las semillas débiles o ambiguas permiten a un atacante presentar un PDA diferente que tu programa aún "acepta".
Reglas generales:
bump = account.bump más tarde (sin búsqueda ambigua de bump en rutas activas).b"vault", etiquetas de versión).#[account(
seeds = [b"vault", authority.key().as_ref(), mint.key().as_ref()],
bump = vault.bump,
)]
pub vault: Account<'info, Vault>,La inicialización escribe discriminadores, autoridades y saldos. Volver a ejecutar la inicialización (o init_if_needed sin un indicador) puede restablecer el administrador al atacante o revivir una forma de cuenta cerrada.
Prefiere init de un solo uso para estado permanente. Si necesitas init_if_needed, requiere !is_initialized (o equivalente) antes de escribir campos de autoridad, y nunca reabras cuentas cerradas sin una ruta deliberada y auditada. Al cerrar, pon a cero los datos / disco y transfiere los lamports para que la cuenta no pueda tratarse como estado activo.
Las compilaciones de lanzamiento de BPF se envuelven en +, -, * simples. Las matemáticas de bóveda, la acuñación de acciones, la acumulación de tarifas y las fórmulas de AMM necesitan checked_* (u operaciones de saturación donde sea intencional) y a menudo intermedios u128 antes de volver a convertir a u64.
El redondeo debe favorecer al protocolo en las mentas y redenciones dirigidas al usuario para que el polvo no pueda ser explotado para obtener valor gratuito. La división por cero y los casos extremos de piscina vacía son errores de seguridad, no meras experiencias de usuario.
La invocación entre programas extiende la confianza a otro programa. Riesgos:
ReentrancyNotAllowed), pero puede mutar cuentas que ya deserializaste, por lo que tu copia en memoria se vuelve obsoleta. Una instrucción de nivel superior posterior en la misma transacción también puede leer saldos que aún parecen pre-actualización.Mitigaciones: lista blanca de llamados con Program<'info, T> o require_keys_eq!; actualiza el estado del programa antes de la CPI externa (CEI); evita las devoluciones de llamada no confiables a menos que diseñes comprobaciones explícitas de deuda al estilo de préstamos rápidos; pasa solo las cuentas que el llamado necesita.
vault.balance = vault.balance.checked_sub(amount).ok_or(ErrorCode::Overflow)?;
// efectos primero, luego interacción
token::transfer(cpi_ctx, amount)?;Solana no es idéntica a la reentrada de EVM, pero un orden de llamada incorrecto y objetivos de CPI no confiables aún pierden fondos.
El trabajo de seguridad es tanto un proceso como código:
Accounts o aritmética.| Capa de control | Lo que captura | Lo que omite | Cuándo apoyarse más |
|---|---|---|---|
| Tipos de cuenta de Anchor | Propietario + disco para Account<T>, muchas restricciones de PDA | Reglas de negocio, rutas no comprobadas | Predeterminado para todas las cuentas de estado |
require_* manual | Restricciones relacionales y económicas | Fácil de omitir en nuevas ixs | Cada revisión de nuevo manejador |
| CEI + lista blanca de programas | Robos clásicos de CPI / programas impostores | Errores de diseño económico | Cualquier movimiento de token o devolución de llamada |
| Matemáticas comprobadas + pruebas de propiedades | Desbordamientos y casos extremos de matemáticas de acciones | Juegos de oráculos y MEV | Bóvedas, AMMs, préstamos |
| Auditoría externa + recompensa | Ojos frescos, clases de catálogo conocidas | Ataques de presupuesto infinito, futuras actualizaciones | Pre-lanzamiento y actualizaciones importantes |
Oráculos son entradas no confiables: verifica el propietario de la fuente, la obsolescencia y la confianza antes de usar precios. Falla cerrado con datos incorrectos.
Extensiones de Token-2022 (hooks, delegados permanentes) cambian quién puede mover tokens. Fija el ID del programa de token; no asumas semántica clásica de SPL Token.
Cierre y alquiler: requiere el firmante y destino correctos; pon a cero los datos para que las cuentas no puedan revivir bajo comprobaciones débiles. Prefiere el close = de Anchor con restricciones.
Autoridad de actualización es la raíz. Multisig o gobernanza, compilaciones verificables y opcionalmente inmutabilidad después de la madurez son seguridad operativa.
Clientes (@solana/kit 7.0.0, billeteras) ayudan solo a usuarios honestos. Los programas defienden contra todos los demás.
En Agave 4.1.1 (CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1), ejercita conjuntos de cuentas adversarias en LiteSVM o validadores locales. Trata cada nueva instrucción como una nueva superficie de ataque.
Todo lo que el llamador puede elegir: qué cuentas y programas aparecen, quién firma, los datos de la instrucción y los objetivos de CPI. El runtime no aplica tus invariantes de menta, autoridad o saldo. Ver Catálogo de Ataques de Sealevel.
Sin un Signer requerido (o ruta invoke_signed de PDA), cualquier clave de cuenta puede ser nombrada como "autoridad" mientras que solo el pagador de la tarifa firma realmente. Eso permite retiros no autorizados y toma de control de administrador. Ver Comprobaciones de Firmante y Propietario.
Pasar una bóveda, cuenta de token, menta o configuración diferente a la que pretende el protocolo, a menudo todavía propiedad de un programa plausible. Solución con restricciones relacionales (has_one, igualdad de menta, semillas). Ver Ataques de Validación de Cuentas.
Si las semillas omiten campos de identidad o los bumps no son canónicos, los atacantes derivan PDAs alternativos que tu instrucción aún acepta, suplantando bóvedas o escrows. Almacena bumps y fija listas completas de semillas. Ver Ataques de PDA y Semillas.
Cuando la inicialización puede ejecutarse nuevamente en estado activo: init_if_needed sin guardas, discriminadores faltantes o cuentas cerradas que se recrean bajo comprobaciones débiles. Ver Ataques de Reinicialización.
Sí, para rutas de valor. La aritmética simple puede envolverse en cadena; las fórmulas de acciones y swaps deben usar checked_* y un redondeo cuidadoso. Ver Aritmética y Desbordamiento.
Comprobaciones-efectos-interacciones: valida, actualiza el estado de tu programa, luego llama externamente. Limita las lecturas al estilo de reentrada de saldos obsoletos durante CPIs no confiables o recursivas. Ver Riesgos de CPI y Reentrada.
Usa Program<'info, Token> (o tu tipo conocido) o require_keys_eq! contra un ID constante. Nunca hagas CPI a una clave de programa proporcionada por el usuario sin una lista blanca explícita.
No. Diferentes IDs de programa y comportamientos de extensión (hooks, tarifas de transferencia, delegados) cambian quién puede mover fondos. Fija el programa y prueba las mentas habilitadas para extensiones.
Cada instrucción mapeada a clases de catálogo, pruebas unitarias negativas, pines de dependencias, notas de compilación verificables y riesgos residuales conocidos. Ver Flujo de Trabajo de Auditoría.
Significa rechazar cuando falta o es inconsistente la prueba requerida: firmante incorrecto, propietario, menta, PDA, oráculo obsoleto o programa no permitido en lista blanca. Las cuentas opcionales aún necesitan reglas explícitas si están presentes.
La seguridad es corrección por instrucción; el paralelismo trata sobre conjuntos de bloqueos. No debilites la validación solo para pasar menos cuentas.
Evita para valor de producción en riesgo. Prefiere multisig o gobernanza, monitorea las actualizaciones y considera congelar la autoridad después de la madurez.
Como entradas no confiables. Verifica el propietario de la fuente, la obsolescencia y la confianza antes de usar precios. Falla cerrado con datos faltantes u obsoletos.
Lee Accounts (firmantes, propietarios, semillas, relaciones, init vs mut, IDs de programa), luego el orden del manejador (matemáticas, escrituras, CPI), luego pruebas negativas para cada modo de fallo.
Versiones de la pila: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 y @solana/kit 7.0.0.
Revisado por Chris St. John·Última actualización: 15 jul 2026