[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-4-primitives-securite-controle-acces-reentrance":3},{"article":4,"author":55},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":7,"meta_description":16,"focus_keyword":17,"og_image":18,"canonical_url":18,"robots_meta":19,"created_at":15,"updated_at":15,"tags":20,"category_name":34,"related_articles":35},"d6000000-0000-0000-0000-000000000104","a0000000-0000-0000-0000-000000000062","Deep EVM #4 : Primitives de sécurité — msg.sender, contrôle d'accès et réentrance","deep-evm-4-primitives-securite-controle-acces-reentrance","Comprenez les primitives de sécurité de l'EVM au niveau des opcodes : comment fonctionne msg.sender, les patterns de contrôle d'accès, les attaques par réentrance et les mécanismes de protection.","## L'identité dans l'EVM : msg.sender\n\nDans l'EVM, l'identité est déterminée par l'opcode CALLER, accessible en Solidity via `msg.sender`. Cet opcode retourne l'adresse de 20 octets qui a initié le contexte d'appel actuel.\n\nPoint crucial : `msg.sender` change à chaque frontière d'appel. Si l'utilisateur A appelle le contrat B qui appelle le contrat C, alors dans C, `msg.sender` est l'adresse de B, pas de A. L'adresse originale est disponible via `tx.origin` (opcode ORIGIN), mais l'utiliser pour l'authentification est une vulnérabilité connue.\n\n### Pourquoi tx.origin est dangereux\n\n```solidity\n\u002F\u002F VULNÉRABLE : attaque de phishing\nfunction withdraw() external {\n    require(tx.origin == owner); \u002F\u002F Ne faites JAMAIS ça\n    payable(msg.sender).transfer(address(this).balance);\n}\n```\n\nUn contrat malveillant peut appeler `withdraw()` — `tx.origin` sera toujours le propriétaire s'il est celui qui a initié la transaction racine.\n\n## Patterns de contrôle d'accès\n\n### Modificateur Ownable\n\nLe pattern le plus simple : un seul propriétaire ayant le contrôle total.\n\n```solidity\naddress public owner;\n\nmodifier onlyOwner() {\n    require(msg.sender == owner, \"Not owner\");\n    _;\n}\n\nfunction criticalAction() external onlyOwner {\n    \u002F\u002F Seul le propriétaire peut exécuter\n}\n```\n\n### Contrôle d'accès basé sur les rôles (RBAC)\n\nPour des permissions plus granulaires, OpenZeppelin's AccessControl :\n\n```solidity\nbytes32 public constant MINTER_ROLE = keccak256(\"MINTER_ROLE\");\nbytes32 public constant PAUSER_ROLE = keccak256(\"PAUSER_ROLE\");\n\nfunction mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) {\n    _mint(to, amount);\n}\n```\n\n## La réentrance : l'attaque classique\n\nLa réentrance se produit quand un contrat effectue un appel externe avant de terminer ses mises à jour d'état internes. Le contrat appelé peut rappeler la fonction vulnérable et exploiter l'état incohérent.\n\n### L'attaque DAO (2016)\n\n```solidity\n\u002F\u002F VULNÉRABLE\nfunction withdraw() external {\n    uint256 balance = balances[msg.sender];\n    (bool success,) = msg.sender.call{value: balance}(\"\");\n    require(success);\n    balances[msg.sender] = 0; \u002F\u002F Trop tard ! L'attaquant a déjà rappelé\n}\n```\n\nL'attaquant déploie un contrat dont la fonction receive() rappelle withdraw() — drainant le contrat à chaque itération avant que le solde ne soit mis à zéro.\n\n### Protection : pattern Checks-Effects-Interactions\n\n```solidity\nfunction withdraw() external {\n    uint256 balance = balances[msg.sender];     \u002F\u002F Check\n    balances[msg.sender] = 0;                    \u002F\u002F Effect\n    (bool success,) = msg.sender.call{value: balance}(\"\"); \u002F\u002F Interaction\n    require(success);\n}\n```\n\nMettez à jour l'état AVANT l'appel externe. Même si l'attaquant rappelle, le solde est déjà à zéro.\n\n### Protection : verrou de réentrance\n\n```solidity\nuint256 private _locked = 1;\n\nmodifier nonReentrant() {\n    require(_locked == 1, \"Reentrant call\");\n    _locked = 2;\n    _;\n    _locked = 1;\n}\n```\n\n## STATICCALL : la protection en lecture seule\n\nL'opcode STATICCALL (EIP-214) garantit qu'un sous-appel ne peut modifier aucun état. Tout opcode de modification (SSTORE, CREATE, LOG, SELFDESTRUCT, CALL avec valeur) provoque un revert immédiat.\n\nUtilisez STATICCALL pour tous les appels de lecture vers des contrats externes non fiables.\n\n## Conclusion\n\nLa sécurité dans l'EVM commence par comprendre les primitives : CALLER pour l'identité, les patterns de contrôle d'accès pour les permissions, et le pattern CEI (Checks-Effects-Interactions) pour la protection contre la réentrance. Ces mécanismes constituent le fondement sur lequel repose la sécurité de tout smart contract.\n\nDans le prochain article, nous introduirons Yul — le langage d'assemblage secret de Solidity.","\u003Ch2 id=\"l-identit-dans-l-evm-msg-sender\">L’identité dans l’EVM : msg.sender\u003C\u002Fh2>\n\u003Cp>Dans l’EVM, l’identité est déterminée par l’opcode CALLER, accessible en Solidity via \u003Ccode>msg.sender\u003C\u002Fcode>. Cet opcode retourne l’adresse de 20 octets qui a initié le contexte d’appel actuel.\u003C\u002Fp>\n\u003Cp>Point crucial : \u003Ccode>msg.sender\u003C\u002Fcode> change à chaque frontière d’appel. Si l’utilisateur A appelle le contrat B qui appelle le contrat C, alors dans C, \u003Ccode>msg.sender\u003C\u002Fcode> est l’adresse de B, pas de A. L’adresse originale est disponible via \u003Ccode>tx.origin\u003C\u002Fcode> (opcode ORIGIN), mais l’utiliser pour l’authentification est une vulnérabilité connue.\u003C\u002Fp>\n\u003Ch3>Pourquoi tx.origin est dangereux\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F VULNÉRABLE : attaque de phishing\nfunction withdraw() external {\n    require(tx.origin == owner); \u002F\u002F Ne faites JAMAIS ça\n    payable(msg.sender).transfer(address(this).balance);\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Un contrat malveillant peut appeler \u003Ccode>withdraw()\u003C\u002Fcode> — \u003Ccode>tx.origin\u003C\u002Fcode> sera toujours le propriétaire s’il est celui qui a initié la transaction racine.\u003C\u002Fp>\n\u003Ch2 id=\"patterns-de-contr-le-d-acc-s\">Patterns de contrôle d’accès\u003C\u002Fh2>\n\u003Ch3>Modificateur Ownable\u003C\u002Fh3>\n\u003Cp>Le pattern le plus simple : un seul propriétaire ayant le contrôle total.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">address public owner;\n\nmodifier onlyOwner() {\n    require(msg.sender == owner, \"Not owner\");\n    _;\n}\n\nfunction criticalAction() external onlyOwner {\n    \u002F\u002F Seul le propriétaire peut exécuter\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Contrôle d’accès basé sur les rôles (RBAC)\u003C\u002Fh3>\n\u003Cp>Pour des permissions plus granulaires, OpenZeppelin’s AccessControl :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">bytes32 public constant MINTER_ROLE = keccak256(\"MINTER_ROLE\");\nbytes32 public constant PAUSER_ROLE = keccak256(\"PAUSER_ROLE\");\n\nfunction mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) {\n    _mint(to, amount);\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"la-r-entrance-l-attaque-classique\">La réentrance : l’attaque classique\u003C\u002Fh2>\n\u003Cp>La réentrance se produit quand un contrat effectue un appel externe avant de terminer ses mises à jour d’état internes. Le contrat appelé peut rappeler la fonction vulnérable et exploiter l’état incohérent.\u003C\u002Fp>\n\u003Ch3>L’attaque DAO (2016)\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F VULNÉRABLE\nfunction withdraw() external {\n    uint256 balance = balances[msg.sender];\n    (bool success,) = msg.sender.call{value: balance}(\"\");\n    require(success);\n    balances[msg.sender] = 0; \u002F\u002F Trop tard ! L'attaquant a déjà rappelé\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>L’attaquant déploie un contrat dont la fonction receive() rappelle withdraw() — drainant le contrat à chaque itération avant que le solde ne soit mis à zéro.\u003C\u002Fp>\n\u003Ch3>Protection : pattern Checks-Effects-Interactions\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">function withdraw() external {\n    uint256 balance = balances[msg.sender];     \u002F\u002F Check\n    balances[msg.sender] = 0;                    \u002F\u002F Effect\n    (bool success,) = msg.sender.call{value: balance}(\"\"); \u002F\u002F Interaction\n    require(success);\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Mettez à jour l’état AVANT l’appel externe. Même si l’attaquant rappelle, le solde est déjà à zéro.\u003C\u002Fp>\n\u003Ch3>Protection : verrou de réentrance\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">uint256 private _locked = 1;\n\nmodifier nonReentrant() {\n    require(_locked == 1, \"Reentrant call\");\n    _locked = 2;\n    _;\n    _locked = 1;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"staticcall-la-protection-en-lecture-seule\">STATICCALL : la protection en lecture seule\u003C\u002Fh2>\n\u003Cp>L’opcode STATICCALL (EIP-214) garantit qu’un sous-appel ne peut modifier aucun état. Tout opcode de modification (SSTORE, CREATE, LOG, SELFDESTRUCT, CALL avec valeur) provoque un revert immédiat.\u003C\u002Fp>\n\u003Cp>Utilisez STATICCALL pour tous les appels de lecture vers des contrats externes non fiables.\u003C\u002Fp>\n\u003Ch2 id=\"conclusion\">Conclusion\u003C\u002Fh2>\n\u003Cp>La sécurité dans l’EVM commence par comprendre les primitives : CALLER pour l’identité, les patterns de contrôle d’accès pour les permissions, et le pattern CEI (Checks-Effects-Interactions) pour la protection contre la réentrance. Ces mécanismes constituent le fondement sur lequel repose la sécurité de tout smart contract.\u003C\u002Fp>\n\u003Cp>Dans le prochain article, nous introduirons Yul — le langage d’assemblage secret de Solidity.\u003C\u002Fp>\n","fr","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:28.870637Z","Primitives de sécurité EVM au niveau opcodes : msg.sender, patterns de contrôle d'accès, attaques par réentrance et mécanismes de protection.","sécurité EVM réentrance",null,"index, follow",[21,26,30],{"id":22,"name":23,"slug":24,"created_at":25},"c0000000-0000-0000-0000-000000000016","EVM","evm","2026-03-28T10:44:21.513630Z",{"id":27,"name":28,"slug":29,"created_at":25},"c0000000-0000-0000-0000-000000000013","Security","security",{"id":31,"name":32,"slug":33,"created_at":25},"c0000000-0000-0000-0000-000000000014","Solidity","solidity","Blockchain",[36,43,49],{"id":37,"title":38,"slug":39,"excerpt":40,"locale":12,"category_name":41,"published_at":42},"d0000000-0000-0000-0000-000000000677","Pourquoi Bali devient le hub impact-tech d'Asie du Sud-Est en 2026","pourquoi-bali-devient-hub-impact-tech-asie-sud-est-2026","Bali se classe 16e parmi les écosystèmes startups d'Asie du Sud-Est. Avec une concentration croissante de bâtisseurs Web3, de startups IA durables et d'entreprises eco-travel tech, l'île se forge une identité de capitale impact-tech de la région.","Ingénierie","2026-03-28T10:44:49.517126Z",{"id":44,"title":45,"slug":46,"excerpt":47,"locale":12,"category_name":41,"published_at":48},"d0000000-0000-0000-0000-000000000676","Le patchwork de la protection des données ASEAN : checklist de conformité pour les développeurs","patchwork-protection-donnees-asean-checklist-conformite-developpeurs","Sept pays de l'ASEAN disposent désormais de lois complètes sur la protection des données, chacune avec des modèles de consentement, des exigences de localisation et des structures de sanctions différents. Voici une checklist pratique de conformité pour les développeurs.","2026-03-28T10:44:49.504560Z",{"id":50,"title":51,"slug":52,"excerpt":53,"locale":12,"category_name":41,"published_at":54},"d0000000-0000-0000-0000-000000000675","La transformation numérique de 29 milliards de dollars d'Indonesia : opportunités pour les éditeurs de logiciels","transformation-numerique-29-milliards-dollars-indonesia-opportunites-editeurs-logiciels","Le marché des services informatiques d'Indonesia devrait atteindre 29,03 milliards de dollars en 2026, contre 24,37 milliards en 2025. L'infrastructure cloud, l'IA, le e-commerce et les centres de données tirent la croissance la plus rapide d'Asie du Sud-Est.","2026-03-28T10:44:49.469231Z",{"id":13,"name":56,"slug":57,"bio":58,"photo_url":18,"linkedin":18,"role":59,"created_at":60,"updated_at":60},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]