diff --git a/src/pentesting-web/dapps-DecentralizedApplications.md b/src/pentesting-web/dapps-DecentralizedApplications.md
new file mode 100644
index 000000000..0759d9c2f
--- /dev/null
+++ b/src/pentesting-web/dapps-DecentralizedApplications.md
@@ -0,0 +1,80 @@
+# DApps - Aplikacje Zdecentralizowane
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Czym jest DApp?
+
+DApp to zdecentralizowana aplikacja, która działa w sieci peer-to-peer, zamiast być hostowana na scentralizowanym serwerze. DApps są zazwyczaj budowane na **technologii blockchain**, co powinno umożliwiać przejrzystość, bezpieczeństwo i niezmienność danych.
+
+## Architektura DApp Web3
+
+Zgodnie z [**tym postem**](https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications) istnieją 3 różne typy architektury DApps Web3:
+
+### DApps "bez API"
+
+Te DApps są budowane na blockchainie i nie polegają na żadnych scentralizowanych API ani backendzie. Można pomyśleć, że blockchain jest rzeczywistym backendem aplikacji. Są **w pełni zdecentralizowane** i można je uzyskać bezpośrednio przez blockchain.
+
+Aby interagować z blockchainem, klient zazwyczaj używa **portfela**. Portfel podpisuje transakcje i wysyła je do blockchaina. Klient może również używać **węzła** do odczytu danych z blockchaina.
+
+### DApps "z API"
+
+Te DApps są budowane na blockchainie, ale również polegają na scentralizowanych API, zazwyczaj w celu zbierania informacji. Są **głównie zdecentralizowane**, ponieważ nawet jeśli polegają na scentralizowanym API, podstawowa funkcjonalność DApp wciąż znajduje się na blockchainie. Komunikacja klienta z blockchainem zazwyczaj odbywa się przez **portfel**.
+
+Dobrym przykładem tego typu DApp jest **aplikacja do mintowania NFT**. Serwer umożliwia przesyłanie obrazów, ale mintowanie odbywa się przez klienta za pomocą portfela.
+
+### DApps "pełnoskalowe"
+
+Te DApps są budowane na blockchainie, ale również polegają na scentralizowanych API i serwerach backendowych. Mogą być **częściowo zdecentralizowane**, ponieważ klient może być w stanie wykonywać operacje na blockchainie za pomocą portfela. Jednak zazwyczaj **backend również będzie w stanie wykonywać operacje na blockchainie**.
+
+Dobrym przykładem tego typu DApp jest most międzyłańcuchowy, gdzie komponent offchain jest potrzebny do **komunikacji z inteligentnymi kontraktami w różnych blockchainach** w celu przeprowadzenia transferu aktywów.
+
+## Wrażliwości Web2
+
+Wrażliwości Web2 wciąż wpływają na tego rodzaju aplikacje, chociaż ich wpływ może się różnić:
+
+- **Wrażliwości po stronie klienta** mają zwiększony wpływ, ponieważ w DApps Web3 klient zazwyczaj jest tym, który **wykonuje operacje na blockchainie** za pomocą portfela. Oznacza to, że ataki takie jak XSS, które udaje się wykonać kod JS po stronie klienta lub które manipulują treścią strony, mogą mieć większy wpływ, ponieważ mogą **interagować z portfelem** i przekonać użytkownika do wykonania niepożądanych operacji na blockchainie.
+- Należy zauważyć, że zazwyczaj nawet w tego rodzaju aplikacjach klient może nadal przeglądać operacje przed ich podpisaniem za pomocą portfela. Jednak jeśli atakujący jest w stanie manipulować treścią strony, może przekonać użytkownika do podpisania transakcji, która wykona niepożądaną operację na blockchainie.
+- **Wrażliwości po stronie serwera** wciąż występują w DApps, które polegają na serwerze backendowym. Wpływ tych wrażliwości będzie zależał od architektury DApp. Mogą być jednak bardzo problematyczne, ponieważ atakujący może znaleźć w backendzie **klucze firmy** do uzyskania dostępu do funduszy inteligentnych kontraktów lub może przeprowadzić przejęcie konta, co może pozwolić mu na kradzież funduszy lub NFT od użytkowników.
+
+Oczywiście, jeśli DApp nie używa backendu lub backend używany oferuje tylko dane publicznego łańcucha lub statyczne strony, powierzchnia ataku DApp jest zmniejszona.
+
+## Powierzchnia ataku Web3
+
+Nawet jeśli ogólnie DApp ma zmniejszoną powierzchnię ataku, ponieważ na blockchainie zawsze są przeprowadzane różne kontrole bezpieczeństwa, wciąż istnieją pewne wektory ataku, które mogą być wykorzystywane przez atakującego.
+
+Możliwe jest pogrupowanie wrażliwości DApps Web3 w następujące kategorie:
+
+- **Niewłaściwie obsługiwane transakcje on-chain**: niepoprawnie sformatowane lub nieograniczone API transakcji, brak logiki oczekiwania na odpowiedź i potwierdzenie bloku, ujawnienie wrażliwych danych oraz niewłaściwe obsługiwanie nieudanych, odwróconych lub wewnętrznie typowanych transakcji, które pozwalają na wstrzykiwanie złośliwych danych.
+
+- **Ataki na backend napędzane inteligentnymi kontraktami**: przechowywanie lub synchronizacja wrażliwych danych między kontraktami a bazami danych bez walidacji, niekontrolowane emisje zdarzeń lub adresy kontraktów oraz podatne na wykorzystanie wrażliwości kontraktów, które mogą zanieczyścić logikę backendu.
+
+- **Błędne operacje na aktywach kryptograficznych**: niewłaściwe przetwarzanie różnych typów tokenów (native vs. ERC-20), ignorowanie precyzji dziesiętnej, nieudane transfery lub transakcje wewnętrzne oraz akceptowanie fałszywych, deflacyjnych, rebase'owych lub podatnych na poślizg tokenów bez walidacji, co umożliwia wstrzykiwanie ładunków za pomocą metadanych tokenów.
+
+Kilka przykładów z [**tego posta**](https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications):
+
+### Marnowanie funduszy: wymuszanie backendu do wykonywania transakcji
+
+W scenariuszu **`Marnowanie kryptowalut w gazie za pomocą nieograniczonego API`**, atakujący może wymusić backend do wywołania funkcji inteligentnego kontraktu, które będą konsumować gaz. Atakujący, wysyłając tylko numer konta ETH i bez limitów, wymusi backend do wywołania inteligentnego kontraktu, aby go zarejestrować, co będzie konsumować gaz.
+
+### DoS: Słaby czas obsługi transakcji
+
+W scenariuszu **`Słaby czas obsługi transakcji prowadzi do DoS`**, wyjaśniono, że ponieważ backend będzie miał otwarte żądanie HTTP, aż transakcja zostanie wykonana, użytkownik może łatwo wysłać kilka żądań HTTP do backendu, co zużyje wszystkie zasoby backendu i doprowadzi do DoS.
+
+### Desynchronizacja Backend<-->Blockchain - Warunek wyścigu
+
+W scenariuszu **`Słaby czas obsługi transakcji prowadzi do warunku wyścigu`**, wyjaśniono, że w grze użytkownik mógł wysłać żądanie wypłaty do backendu, który wyśle użytkownikowi jego monety, ale podczas gdy transakcja była wciąż przetwarzana, użytkownik mógł użyć tych monet do zakupu przedmiotów w grze, otrzymując je za darmo.
+
+Innym przykładem może być możliwość użycia tych samych monet do zakupu różnych przedmiotów, ponieważ backend natychmiastowo przekazuje przedmiot użytkownikowi, nie czekając na potwierdzenie transakcji, a tym samym nie czekając na zmniejszenie salda użytkownika w blockchainie.
+
+### Walidacja adresu inteligentnego kontraktu
+
+W scenariuszu **`Backend mostu nie ma walidacji adresu inteligentnego kontraktu`** wyjaśniono, jak backend sprawdzał adres inteligentnego kontraktu, więc atakujący mógł wdrożyć fałszywy inteligentny kontrakt, umieścić na nim fundusze, wysłać transakcję do backendu, a backend pomyśli, że użytkownik wysłał fundusze do prawdziwego inteligentnego kontraktu i przyzna użytkownikowi tokeny.
+
+### Niewłaściwe zarządzanie klasami aktywów
+
+W scenariuszu **`Niewłaściwe zarządzanie klasami aktywów`**, wyjaśniono, że backend pomylił oszukańczego NFT w adresie z 1 MATIC, co pozwoliło atakującemu wysłać setki oszukańczych NFT do adresu i otrzymać 1 MATIC z platformy za każdy z nich.
+
+## Referencje
+- [https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications](https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications)
+
+{{#include ../../banners/hacktricks-training.md}}