diff --git a/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md b/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md
index 897a66ffe..a342106a6 100644
--- a/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md
+++ b/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md
@@ -195,7 +195,7 @@ Both tools verstaan **AArch64** kodering en sal kandidaat `mov x8, 0x8b ; svc #0
 
 ## Ketting SROP met ROP (pivot via `mprotect`)
 
-`rt_sigreturn` laat ons toe om *alle* algemene registers en `pstate` te beheer.  'n Algemene patroon op x86 is: 1) gebruik SROP om `mprotect` aan te roep, 2) pivot na 'n nuwe uitvoerbare stapel wat shell-code bevat. Dieselfde idee werk op ARM64:
+`rt_sigreturn` laat ons toe om *alle* algemene registers en `pstate` te beheer.  'n Algemene patroon op x86 is: 1) gebruik SROP om `mprotect` aan te roep, 2) pivot na 'n nuwe uitvoerbare stapel wat shell-code bevat.  Dieselfde idee werk op ARM64:
 ```python
 frame = SigreturnFrame()
 frame.x8 = constants.SYS_mprotect   # 226
diff --git a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
index e65667ae1..f7e2fdb3c 100644
--- a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
+++ b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
@@ -105,9 +105,9 @@ app.run()
 ```
 #### Nuwe (2023-2025) CSP omseil tegnieke met iframes
 
-Die navorsingsgemeenskap gaan voort om kreatiewe maniere te ontdek om iframes te misbruik om beperkende beleide te oorwin. Hieronder kan jy die mees noemenswaardige tegnieke vind wat gedurende die laaste paar jaar gepubliseer is:
+Die navorsingsgemeenskap gaan voort om kreatiewe maniere te ontdek om iframes te misbruik om beperkende beleide te oorwin. Hieronder kan jy die mees noemenswaardige tegnieke vind wat gedurende die afgelope paar jaar gepubliseer is:
 
-* **Dangling-markup / named-iframe data-exfiltration (PortSwigger 2023)** – Wanneer 'n toepassing HTML reflekteer maar 'n sterk CSP script uitvoering blokkeer, kan jy steeds sensitiewe tokens lek deur 'n *dangling* `<iframe name>` attribuut in te spuit. Sodra die gedeeltelike markup geanaliseer is, navigeer die aanvaller se script wat in 'n aparte oorsprong loop die raam na `about:blank` en lees `window.name`, wat nou alles bevat tot by die volgende aanhalingsteken (byvoorbeeld 'n CSRF-token). Omdat daar geen JavaScript in die slagoffer se konteks loop nie, ontduik die aanval gewoonlik `script-src 'none'`. 'n Minimale PoC is:
+* **Dangling-markup / named-iframe data-exfiltration (PortSwigger 2023)** – Wanneer 'n toepassing HTML reflekteer maar 'n sterk CSP script uitvoering blokkeer, kan jy steeds sensitiewe tokens lek deur 'n *dangling* `<iframe name>` attribuut in te voeg. Sodra die gedeeltelike markup geparseer is, navigeer die aanvaller script wat in 'n aparte oorsprong loop die raam na `about:blank` en lees `window.name`, wat nou alles bevat tot by die volgende aanhalingsteken karakter (byvoorbeeld 'n CSRF token). Omdat daar geen JavaScript in die slagoffer se konteks loop nie, ontduik die aanval gewoonlik `script-src 'none'`. 'n Minimale PoC is:
 
 ```html
 <!-- Injection point just before a sensitive <script> -->
@@ -120,7 +120,7 @@ victim.location = 'about:blank';
 console.log(victim.name); // → leaked value
 ```
 
-* **Nonce diefstal via same-origin iframe (2024)** – CSP nonces word nie uit die DOM verwyder nie; hulle word bloot in DevTools versteek. As 'n aanvaller 'n *same-origin* iframe kan inspuit (byvoorbeeld deur HTML na die webwerf op te laai) kan die kindraam eenvoudig `document.querySelector('[nonce]').nonce` vra en nuwe `<script nonce>` nodes skep wat aan die beleid voldoen, wat volle JavaScript uitvoering moontlik maak ten spyte van `strict-dynamic`. Die volgende gadget eskaleer 'n markup inspuiting in XSS:
+* **Nonce diefstal via same-origin iframe (2024)** – CSP nonces word nie uit die DOM verwyder nie; hulle word bloot in DevTools versteek. As 'n aanvaller 'n *same-origin* iframe kan inbring (byvoorbeeld deur HTML na die webwerf op te laai) kan die kindraam eenvoudig `document.querySelector('[nonce]').nonce` vra en nuwe `<script nonce>` nodes skep wat aan die beleid voldoen, wat volle JavaScript uitvoering moontlik maak ten spyte van `strict-dynamic`. Die volgende gadget eskaleer 'n markup-inspuiting in XSS:
 
 ```javascript
 const n = top.document.querySelector('[nonce]').nonce;
@@ -130,14 +130,14 @@ s.nonce = n;
 top.document.body.appendChild(s);
 ```
 
-* **Form-action hijacking (PortSwigger 2024)** – 'n Bladsy wat die `form-action` riglyn omseil, kan sy aanmeldvorm *herdoel* van 'n ingespuite iframe of inline HTML sodat wagwoordbestuurders outomaties inligting invul en aan 'n eksterne domein indien, selfs wanneer `script-src 'none'` teenwoordig is. Vul altyd `default-src` aan met `form-action`!
+* **Form-action hijacking (PortSwigger 2024)** – 'n Bladsy wat die `form-action` riglyn omseil, kan sy aanmeldvorm *herdoel* van 'n ingebrachte iframe of inline HTML sodat wagwoordbestuurders outomaties inligting invul en akrediteer aan 'n eksterne domein, selfs wanneer `script-src 'none'` teenwoordig is. Vul altyd `default-src` aan met `form-action`!
 
 **Verdedigende notas (vinnige kontrolelys)**
 
 1. Stuur altyd *alle* CSP riglyne wat sekondêre kontekste beheer (`form-action`, `frame-src`, `child-src`, `object-src`, ens.).
-2. Moet nie staatmaak op nonces wat geheim is nie—gebruik `strict-dynamic` **en** elimineer inspuitpunte.
+2. Moet nie staatmaak op nonces wat geheim is nie—gebruik `strict-dynamic` **en** elimineer inspuitingspunte.
 3. Wanneer jy onbetroubare dokumente moet inkorporeer, gebruik `sandbox="allow-scripts allow-same-origin"` **baie versigtig** (of sonder `allow-same-origin` as jy net script uitvoering isolasie benodig).
-4. Oorweeg 'n verdediging-in-diepte COOP+COEP implementering; die nuwe `<iframe credentialless>` attribuut (§ hieronder) laat jou toe om dit te doen sonder om derdeparty insluitings te breek.
+4. Oorweeg 'n verdediging-in-diepte COOP+COEP implementering; die nuwe `<iframe credentialless>` attribuut (§ hieronder) laat jou toe om dit te doen sonder om derdeparty inskrywings te breek.
 
 ### Ander Payloads gevind in die natuur <a href="#other_payloads_found_on_the_wild_64" id="#other_payloads_found_on_the_wild_64"></a>
 ```html
@@ -177,11 +177,11 @@ Die attribuut se waarde kan leeg gelaat word (`sandbox=""`) om al die bogenoemde
 
 Soos verduidelik in [this article](https://blog.slonser.info/posts/make-self-xss-great-again/), die `credentialless` vlag in 'n iframe word gebruik om 'n bladsy binne 'n iframe te laai sonder om kredensiale in die versoek te stuur terwyl die dieselfde oorsprong beleid (SOP) van die gelaaide bladsy in die iframe gehandhaaf word.
 
-Sedert **Chrome 110 (Februarie 2023) is die funksie standaard geaktiveer** en die spesifikasie word gestandaardiseer oor blaaiers onder die naam *anonymous iframe*. MDN beskryf dit as: “'n meganisme om derdeparty iframes in 'n splinternuwe, ephemerale stoorpartisie te laai sodat geen koekies, localStorage of IndexedDB gedeel word met die werklike oorsprong”. Gevolge vir aanvallers en verdedigers:
+Sedert **Chrome 110 (Februarie 2023) is die funksie standaard geaktiveer** en die spesifikasie word gestandaardiseer oor blaaiers onder die naam *anonymous iframe*. MDN beskryf dit as: “'n mekanisme om derdeparty iframes in 'n splinternuwe, ephemerale stoorpartisie te laai sodat geen koekies, localStorage of IndexedDB gedeel word met die werklike oorsprong”. Gevolge vir aanvallers en verdedigers:
 
-* Skrifte in verskillende credentialless iframes **deel steeds dieselfde top-niveau oorsprong** en kan vrylik via die DOM interaksie hê, wat multi-iframe self-XSS-aanvalle haalbaar maak (sien PoC hieronder).
-* Omdat die netwerk **credential-stripped** is, gedra enige versoek binne die iframe effektief soos 'n nie-geverifieerde sessie – CSRF-beskermde eindpunte faal gewoonlik, maar openbare bladsye wat via DOM gelek kan word, is steeds in omvang.
-* Pop-ups wat uit 'n credentialless iframe ontstaan, kry 'n implisiete `rel="noopener"`, wat sommige OAuth-strome breek.
+* Skrifte in verskillende credentialless iframes **deel steeds dieselfde topvlak oorsprong** en kan vrylik via die DOM interaksie hê, wat multi-iframe self-XSS-aanvalle haalbaar maak (sien PoC hieronder).
+* Omdat die netwerk **credential-stripped** is, gedra enige versoek binne die iframe effektief soos 'n onaangetekende sessie – CSRF-beskermde eindpunte faal gewoonlik, maar openbare bladsye wat via DOM gelekt kan word, is steeds in omvang.
+* Pop-ups wat uit 'n credentialless iframe ontstaan, kry 'n implisiete `rel="noopener"`, wat sommige OAuth vloei breek.
 ```javascript
 // PoC: two same-origin credentialless iframes stealing cookies set by a third
 window.top[1].document.cookie = 'foo=bar';            // write
@@ -191,7 +191,7 @@ alert(window.top[2].document.cookie);                 // read -> foo=bar
 
 In hierdie aanval berei die aanvaller 'n kwaadwillige webblad voor met 2 iframes:
 
-- 'n iframe wat die slagoffer se bladsy laai met die `credentialless` vlag met 'n CSRF wat 'n XSS aktiveer (Stel jou 'n Self-XSS in die gebruikersnaam van die gebruiker voor):
+- 'n iframe wat die slagoffer se bladsy laai met die `credentialless` vlag met 'n CSRF wat 'n XSS aktiveer (Stel jou 'n Self-XSS in die gebruiker se gebruikersnaam voor):
 ```html
 <html>
 <body>
@@ -215,7 +215,7 @@ alert(window.top[1].document.cookie);
 ```
 ### fetchLater Aanval
 
-Soos aangedui in [hierdie artikel](https://blog.slonser.info/posts/make-self-xss-great-again/) laat die API `fetchLater` toe om 'n versoek te konfigureer wat later uitgevoer moet word (na 'n sekere tyd). Daarom kan dit misbruik word om byvoorbeeld 'n slagoffer binne 'n aanvaller se sessie in te log (met Self-XSS), 'n `fetchLater` versoek in te stel (om die wagwoord van die huidige gebruiker te verander byvoorbeeld) en uit te log uit die aanvaller se sessie. Dan log die slagoffer in in sy eie sessie en die `fetchLater` versoek sal uitgevoer word, wat die wagwoord van die slagoffer verander na die een wat deur die aanvaller gestel is.
+Soos aangedui in [this article](https://blog.slonser.info/posts/make-self-xss-great-again/) laat die API `fetchLater` toe om 'n versoek te konfigureer wat later uitgevoer sal word (na 'n sekere tyd). Daarom kan dit misbruik word om byvoorbeeld 'n slagoffer binne 'n aanvaller se sessie in te log (met Self-XSS), 'n `fetchLater` versoek in te stel (om die wagwoord van die huidige gebruiker te verander byvoorbeeld) en uit te log uit die aanvaller se sessie. Dan log die slagoffer in sy eie sessie in en die `fetchLater` versoek sal uitgevoer word, wat die wagwoord van die slagoffer verander na die een wat deur die aanvaller gestel is.
 
 Op hierdie manier, selfs al kan die slagoffer se URL nie in 'n iframe gelaai word nie (as gevolg van CSP of ander beperkings), kan die aanvaller steeds 'n versoek in die slagoffer se sessie uitvoer.
 ```javascript