We worden aangevallen! 23+ Node.js best practices voor beveiliging

We worden aangevallen! 23+ Node.js best practices voor beveiliging

Verzameld, samengesteld en geschreven door: Yoni Goldberg, Kyle Martin en Bruno Scheufler

Technische recensent: Liran Tal (Node.js Security Working Group)

Welkom bij onze uitgebreide lijst met best practices voor beveiliging van Node.js die de best gerangschikte artikelen en blogberichten samenvat en samenstelt

Enkele woorden voordat we beginnen

Webaanvallen exploderen tegenwoordig als beveiliging aan de voorkant van het podium komt. We hebben meer dan 23 Node.js best practices op het gebied van beveiliging (+40 andere generieke beveiligingspraktijken) samengesteld uit alle topartikelen over de hele wereld. Het werk hier maakt deel uit van onze best practices GitHub-repository van Node.js die meer dan 80 Node.js-praktijken bevat. Opmerking: Veel items hebben een lees meer link naar een uitwerking over het onderwerp met codevoorbeeld en andere nuttige informatie.

Ontvang wekelijkse best practices via onze Twitter-feed

1. Omarm de beveiligingsregels van de linter

TL; DR: maak gebruik van beveiligingsgerelateerde linterplug-ins zoals eslint-plugin-beveiliging om beveiligingsproblemen en -problemen zo vroeg mogelijk op te vangen - terwijl ze worden gecodeerd. Dit kan helpen beveiligingslekken op te lossen, zoals het gebruik van eval, het aanroepen van een kindproces of het importeren van een module met een niet-letterlijke letterlijke waarde (bijvoorbeeld gebruikersinvoer). Klik hieronder op 'Meer lezen' om codevoorbeelden te zien die worden opgepakt door een beveiligingslinter

Anders: wat een eenvoudige beveiligingszwakte had kunnen zijn tijdens de ontwikkeling, wordt een groot probleem in de productie. Het is ook mogelijk dat het project geen consistente praktijken voor codebeveiliging volgt, waardoor kwetsbaarheden worden geïntroduceerd of gevoelige geheimen worden begaan in externe opslagplaatsen

Lees meer: ​​Linterregels

Linting hoeft niet alleen maar een hulpmiddel te zijn om pedantische regels af te dwingen over witruimte, puntkomma's of eval-statements. ESLint biedt een krachtig raamwerk voor het elimineren van een breed scala aan potentieel gevaarlijke patronen in uw code (reguliere expressies, invoervalidatie, enzovoort). Ik denk dat het een krachtige nieuwe tool is die het overwegen waard is door beveiligingsbewuste JavaScript-ontwikkelaars. (Adam Baldwin)
Meer citaten en codevoorbeelden hier

2. Beperk gelijktijdige aanvragen met behulp van een middleware

TL; DR: DOS-aanvallen zijn erg populair en relatief gemakkelijk uit te voeren. Implementeer snelheidsbeperking met behulp van een externe service zoals cloud load balancers, cloud firewalls, nginx, rate-limiter-flexibel pakket of (voor kleinere en minder kritische apps) een snelheidsbeperkende middleware (bijv. Express-rate-limit)

Anders: een applicatie kan worden onderworpen aan een aanval die resulteert in een denial of service waarbij echte gebruikers een verslechterde of niet-beschikbare service ontvangen.

Lees meer: ​​Implementeer snelheidsbeperking

3. Haal geheimen uit configuratiebestanden of gebruik pakketten om ze te coderen

TL; DR: sla nooit geheime tekstgeheimen op in configuratiebestanden of broncode. Gebruik in plaats daarvan geheime beheerssystemen zoals Vault-producten, Kubernetes / Docker Secrets of gebruik omgevingsvariabelen. Als laatste resultaat moeten geheimen die zijn opgeslagen in bronbeheer worden gecodeerd en beheerd (sleutels rollen, verlopen, auditing, enz.). Maak gebruik van pre-commit / push hooks om per ongeluk geheimen te voorkomen

Anders: Bronbeheer, zelfs voor privérepository's, kan per ongeluk openbaar worden gemaakt, waarna alle geheimen worden onthuld. Toegang tot bronbeheer voor een externe partij geeft onbedoeld toegang tot gerelateerde systemen (databases, apis, services, enz.).

Lees meer: ​​Geheim beheer

4. Voorkom kwetsbaarheden bij zoekopdrachtinjectie met ORM / ODM-bibliotheken

TL; DR: om SQL / NoSQL-injectie en andere kwaadwillende aanvallen te voorkomen, moet u altijd gebruik maken van een ORM / ODM of een databasebibliotheek die gegevens ontsnapt of benoemde of geïndexeerde geparametriseerde zoekopdrachten ondersteunt en zorgt voor het valideren van gebruikersinvoer voor verwachte typen. Gebruik nooit alleen JavaScript-templatereeksen of tekenreeksen om waarden in query's te injecteren, omdat dit uw toepassing voor een breed spectrum van kwetsbaarheden opent. Alle gerenommeerde Node.js datatoegangsbibliotheken (bijv. Sequelize, Knex, mangoest) hebben ingebouwde bescherming tegen injectie-aanvallen

Anders: niet-gevalideerde of niet-gesanitiseerde gebruikersinvoer kan leiden tot operatorinjectie bij het werken met MongoDB voor NoSQL, en als u geen goed saneringssysteem of ORM gebruikt, kunnen SQL-injectie-aanvallen gemakkelijk worden toegestaan, waardoor een enorme kwetsbaarheid ontstaat.

Lees meer: ​​Query-injectiepreventie met behulp van ORM / ODM-bibliotheken

Waardeer de moeite? Geef ons project een ster op GitHub

5. Vermijd DOS-aanvallen door expliciet in te stellen wanneer een proces vastloopt

TL; DR: het knooppuntproces loopt vast wanneer fouten niet worden afgehandeld. Veel best practices raden zelfs aan om af te sluiten, ook al is er een fout opgetreden die is verholpen. Express crasht bijvoorbeeld bij elke asynchrone fout, tenzij u routes omwikkelt met een vangclausule. Dit opent een zeer zoete aanvalsplek voor aanvallers die herkennen welke invoer het proces doet crashen en herhaaldelijk hetzelfde verzoek verzenden. Er is geen onmiddellijke oplossing hiervoor, maar een paar technieken kunnen de pijn verlichten: waarschuw met kritieke ernst wanneer een proces crasht vanwege een onverwerkte fout, valideer de invoer en vermijd crashen van het proces vanwege ongeldige gebruikersinvoer, omwikkel alle routes met een vangst en overweeg niet te crashen wanneer een fout in een verzoek is ontstaan ​​(in tegenstelling tot wat er wereldwijd gebeurt)

Anders: dit is slechts een onderbouwde gok: gezien veel Node.js-applicaties, als we proberen een lege JSON-body door te geven aan alle POST-aanvragen, crasht een handvol applicaties. Op dat moment kunnen we gewoon hetzelfde verzoek herhalen om de applicaties gemakkelijk te verwijderen

6. Pas de HTTP-antwoordkoppen aan voor verbeterde beveiliging

TL; DR: uw toepassing moet beveiligde headers gebruiken om te voorkomen dat aanvallers algemene aanvallen zoals cross-site scripting (XSS), clickjacking en andere kwaadaardige aanvallen gebruiken. Deze kunnen eenvoudig worden geconfigureerd met behulp van modules zoals een helm.

Anders: aanvallers kunnen directe aanvallen uitvoeren op de gebruikers van uw applicatie, wat leidt tot enorme beveiligingsproblemen

Lees meer: ​​Veilige headers gebruiken in uw applicatie

7. Inspecteer constant en automatisch op kwetsbare afhankelijkheden

TL; DR: Met het npm-ecosysteem is het gebruikelijk dat er veel afhankelijkheden zijn voor een project. Afhankelijkheden moeten altijd onder controle worden gehouden wanneer nieuwe kwetsbaarheden worden gevonden. Gebruik tools zoals npm audit, nsp of snyk om kwetsbare afhankelijkheden op te sporen, te bewaken en te patchen. Integreer deze tools met uw CI-installatie, zodat u een kwetsbare afhankelijkheid krijgt voordat deze in productie komt.

Anders: een aanvaller kan uw webframework detecteren en alle bekende kwetsbaarheden aanvallen.

Lees meer: ​​afhankelijkheidsbeveiliging

8. Gebruik de cryptobibliotheek Node.js niet om wachtwoorden te verwerken, gebruik Bcrypt

TL; DR: wachtwoorden of geheimen (API-sleutels) moeten worden opgeslagen met behulp van een veilige hash + salt-functie zoals bcrypt, die vanwege prestaties en veiligheidsredenen de voorkeur verdient boven de JavaScript-implementatie.

Anders: wachtwoorden of geheimen die worden bewaard zonder een beveiligde functie te gebruiken, zijn kwetsbaar voor brute dwingen en woordenboekaanvallen die uiteindelijk tot onthulling zullen leiden.

Lees meer: ​​Gebruik Bcrypt

9. Ontsnap aan HTML-, JS- en CSS-uitvoer

TL; DR: niet-vertrouwde gegevens die naar de browser worden verzonden, kunnen mogelijk worden uitgevoerd in plaats van alleen te worden weergegeven, dit wordt meestal een XSS-aanval (cross-site-scripting) genoemd. Beperk dit door speciale bibliotheken te gebruiken die de gegevens expliciet markeren als pure inhoud die nooit mag worden uitgevoerd (d.w.z. codering, escaping)

Anders: een aanvaller kan een schadelijke JavaScript-code in uw DB opslaan die vervolgens als zodanig naar de arme clients wordt verzonden

Lees meer: ​​Escape-uitgang

10. Valideer inkomende JSON-schema's

TL; DR: valideer de bodyload van de binnenkomende aanvragen en zorg ervoor dat deze aan de verwachtingen voldoet, faal snel als dat niet het geval is. Om vervelende validatiecodering binnen elke route te voorkomen, kunt u lichtgewicht op JSON gebaseerde validatieschema's gebruiken, zoals jsonschema of joi

Anders: je vrijgevigheid en tolerante aanpak vergroot het aanvalsoppervlak aanzienlijk en moedigt de aanvaller aan om veel ingangen uit te proberen totdat ze een combinatie vinden om de applicatie te laten crashen

Lees meer: ​​inkomende JSON-schema's valideren

11. Ondersteuning van zwarte lijst JWT-tokens

TL; DR: Bij het gebruik van JWT-tokens (bijvoorbeeld met Passport.js) is er standaard geen mechanisme om de toegang van uitgegeven tokens te herroepen. Zodra u schadelijke gebruikersactiviteit ontdekt, is er geen manier om te voorkomen dat ze toegang krijgen tot het systeem zolang ze een geldig token hebben. Beperk dit door een zwarte lijst van niet-vertrouwde tokens te implementeren die voor elk verzoek worden gevalideerd.

Anders: verlopen of misplaatste tokens kunnen door een derde kwaadwillend worden gebruikt om toegang te krijgen tot een toepassing en zich voor te doen als de eigenaar van het token.

Lees meer: ​​JWT's op de zwarte lijst plaatsen

12. Voorkom brute-force aanvallen tegen autorisatie

TL; DR: een eenvoudige en krachtige techniek is het beperken van autorisatiepogingen met behulp van twee statistieken:

  1. De eerste is het aantal opeenvolgende mislukte pogingen door dezelfde gebruiker unieke ID / naam en hetzelfde IP-adres.
  2. De tweede is het aantal mislukte pogingen van een IP-adres gedurende een lange periode van tijd. Blokkeer bijvoorbeeld een IP-adres als het 100 mislukte pogingen op één dag doet.

Anders: een aanvaller kan onbeperkte geautomatiseerde wachtwoordpogingen uitvoeren om toegang te krijgen tot bevoorrechte accounts in een toepassing

Lees meer: ​​Aanmeldingssnelheid beperken

13. Voer Node.js uit als niet-rootgebruiker

TL; DR: Er is een veel voorkomend scenario waarin Node.js wordt uitgevoerd als een rootgebruiker met onbeperkte machtigingen. Dit is bijvoorbeeld het standaardgedrag in Docker-containers. Het wordt aanbevolen om een ​​niet-rootgebruiker te maken en deze in de Docker-afbeelding te bakken (voorbeelden hieronder) of het proces namens deze gebruikers uit te voeren door de container met de vlag "-u gebruikersnaam" aan te roepen

Anders: een aanvaller die erin slaagt een script op de server uit te voeren, krijgt onbeperkte macht over de lokale machine (bijv. Iptable wijzigen en verkeer omleiden naar zijn server)

Lees meer: ​​voer Node.js uit als niet-rootgebruiker

14. Beperk de grootte van de lading met behulp van een reverse-proxy of een middleware

TL; DR: Hoe groter de laadcapaciteit van het lichaam, hoe moeilijker uw enkele thread werkt bij het verwerken. Dit is een kans voor aanvallers om servers op hun knieën te brengen zonder enorm veel verzoeken (DOS / DDOS-aanvallen). Beperk dit de lichaamslengte van inkomende verzoeken aan de rand (bijv. Firewall, ELB) of door express body parser te configureren om alleen kleine payloads te accepteren

Anders: uw applicatie zal grote aanvragen moeten verwerken, niet in staat om het andere belangrijke werk dat het moet doen te verwerken, wat leidt tot implicaties voor de prestaties en kwetsbaarheid voor DOS-aanvallen

Lees meer: ​​Beperk de grootte van de lading

Ontvang wekelijkse best practices via onze Twitter-feed

15. Vermijd JavaScript eval statements

TL; DR: eval is slecht omdat het tijdens de uitvoering een aangepaste JavaScript-code kan uitvoeren. Dit is niet alleen een prestatieprobleem, maar ook een belangrijk beveiligingsprobleem vanwege schadelijke JavaScript-code die afkomstig kan zijn van gebruikersinvoer. Een ander taalkenmerk dat moet worden vermeden, is de nieuwe functieconstructor. setTimeout en setInterval mogen ook nooit dynamische JavaScript-code worden doorgegeven.

Anders: kwaadaardige JavaScript-code vindt een weg in een tekst die wordt doorgegeven aan eval of andere realtime evaluerende JavaScript-taalfuncties en krijgt volledige toegang tot JavaScript-machtigingen op de pagina. Dit beveiligingslek manifesteert zich vaak als een XSS-aanval.

Meer lezen: vermijd evalentieverklaringen voor JavaScript

16. Voorkom dat kwaadaardige RegEx uw uitvoering van één thread overbelast

TL; DR: Reguliere expressies vormen weliswaar handig, maar vormen een reële bedreiging voor JavaScript-applicaties in het algemeen en het Node.js-platform in het bijzonder. Een gebruikersinvoer voor overeenkomende tekst kan een uitzonderlijk aantal CPU-cycli vereisen om te verwerken. RegEx-verwerking kan inefficiënt zijn in die mate dat een enkele aanvraag die 10 woorden valideert, de hele gebeurtenislus gedurende 6 seconden kan blokkeren en de CPU op kan zetten. Geef daarom de voorkeur aan validatiepakketten van derden zoals validator.js in plaats van uw eigen Regex-patronen te schrijven, of gebruik safe-regex om kwetsbare regex-patronen te detecteren

Anders: Slecht geschreven regexen kunnen vatbaar zijn voor DoS-aanvallen met reguliere expressie die de gebeurtenislus volledig blokkeren. Het populaire momentpakket werd bijvoorbeeld kwetsbaar bevonden door schadelijk RegEx-gebruik in november 2017

Lees meer: ​​Voorkom schadelijke RegEx

17. Vermijd het laden van modules met behulp van een variabele

TL; DR: vermijd het nodig / importeren van een ander bestand met een pad dat als parameter is opgegeven vanwege de bezorgdheid dat het afkomstig zou kunnen zijn van gebruikersinvoer. Deze regel kan worden uitgebreid voor toegang tot bestanden in het algemeen (d.w.z. fs.readFile ()) of andere gevoelige brontoegang met dynamische variabelen die afkomstig zijn van gebruikersinvoer. Eslint-plugin-beveiligingslinter kan dergelijke patronen opvangen en vroeg genoeg waarschuwen

Anders: kwaadwillende gebruikersinvoer kan zijn weg vinden naar een parameter die wordt gebruikt om geknoeide bestanden te vereisen, bijvoorbeeld een eerder geüpload bestand op het bestandssysteem, of toegang tot reeds bestaande systeembestanden.

Lees meer: ​​Veilig module laden

18. Voer onveilige code uit in een sandbox

TL; DR: wanneer u wordt belast met het uitvoeren van externe code die tijdens runtime wordt gegeven (bijv. Plug-in), gebruikt u een willekeurige 'sandbox'-uitvoeringsomgeving die de hoofdcode isoleert en bewaakt tegen de plug-in. Dit kan worden bereikt met behulp van een specifiek proces (bijv. Cluster.fork ()), serverloze omgeving of speciale npm-pakketten die als een sandbox fungeren

Anders: een plug-in kan aanvallen via een eindeloze verscheidenheid aan opties, zoals oneindige lussen, geheugenoverbelasting en toegang tot gevoelige procesomgevingsvariabelen

Lees meer: ​​voer onveilige code uit in een sandbox

19. Wees extra voorzichtig bij het werken met kindprocessen

TL; DR: vermijd indien mogelijk het gebruik van onderliggende processen en valideer en zuiver input om shell-injectie-aanvallen te verminderen als dat nog moet. Gebruik bij voorkeur child_process.execFile dat per definitie slechts één opdracht met een set attributen uitvoert en uitbreiding van de shell-parameter niet toestaat.

Anders: naïef gebruik van onderliggende processen kan leiden tot het uitvoeren van externe opdrachten of shell-injectieaanvallen vanwege kwaadwillende gebruikersinvoer die wordt doorgegeven aan een niet-gesanitiseerde systeemopdracht.

Lees meer: ​​Wees voorzichtig bij het werken met kindprocessen

20. Verberg foutdetails voor clients

TL; DR: een geïntegreerde express-foutafhandelaar verbergt standaard de foutdetails. Groot is echter de kans dat u uw eigen foutafhandelingslogica implementeert met aangepaste Error-objecten (door velen beschouwd als een best practice). Als u dit doet, moet u ervoor zorgen dat u niet het volledige object Error naar de client retourneert, omdat dit mogelijk gevoelige toepassingsdetails bevat

Anders: Gevoelige applicatiegegevens zoals serverbestandspaden, gebruikte modules van derden en andere interne workflows van de applicatie die door een aanvaller kunnen worden misbruikt, kunnen worden gelekt uit informatie in een stack-trace

Meer lezen: foutdetails verbergen voor clients

21. Configureer 2FA voor npm of Yarn

TL; DR: Elke stap in de ontwikkelingsketen moet worden beschermd met MFA (multi-factor authentication), npm / Yarn zijn een mooie kans voor aanvallers die het wachtwoord van een ontwikkelaar in handen kunnen krijgen. Met behulp van de inloggegevens van ontwikkelaars kunnen aanvallers schadelijke code in bibliotheken injecteren die op grote schaal zijn geïnstalleerd in projecten en services. Misschien zelfs op internet als deze in het openbaar wordt gepubliceerd. Als u 2-factor-authenticatie in npm inschakelt, hebben aanvallers bijna nul kansen om uw pakketcode te wijzigen.

Anders: heb je gehoord over de eslint-ontwikkelaar wiens wachtwoord is gekaapt?

22. Wijzig sessie middleware-instellingen

TL; DR: elk webframework en -technologie heeft zijn bekende zwakke punten - een aanvaller vertellen welk webframework we gebruiken is een grote hulp voor hen. Door de standaardinstellingen voor sessiemiddlewares te gebruiken, kan uw app op dezelfde manier worden blootgesteld aan module- en framework-specifieke kapingaanvallen als de X-Powered-By-header. Probeer alles te verbergen dat uw technische stapel identificeert en onthult (bijv. Node.js, express)

Anders: cookies kunnen via onveilige verbindingen worden verzonden en een aanvaller kan sessie-identificatie gebruiken om het onderliggende raamwerk van de webtoepassing te identificeren, evenals modulespecifieke kwetsbaarheden

Lees meer: ​​Cookie- en sessiebeveiliging

23. Vermijd DOS-aanvallen door expliciet in te stellen wanneer een proces vastloopt

TL; DR: het knooppuntproces loopt vast wanneer fouten niet worden afgehandeld. Veel best practices raden zelfs aan om af te sluiten, ook al is er een fout opgetreden die is verholpen. Express crasht bijvoorbeeld bij elke asynchrone fout, tenzij u routes omwikkelt met een vangclausule. Dit opent een zeer zoete aanvalsplek voor aanvallers die herkennen welke invoer het proces doet crashen en herhaaldelijk hetzelfde verzoek verzenden. Er is geen onmiddellijke oplossing hiervoor, maar een paar technieken kunnen de pijn verlichten: waarschuw met kritieke ernst wanneer een proces crasht vanwege een onverwerkte fout, valideer de invoer en vermijd crashen van het proces vanwege ongeldige gebruikersinvoer, verpak alle routes met een vangst en overweeg niet te crashen wanneer een fout in een verzoek is ontstaan ​​(in tegenstelling tot wat er wereldwijd gebeurt)

Anders: dit is slechts een onderbouwde gok: gezien veel Node.js-applicaties, als we proberen een lege JSON-body door te geven aan alle POST-aanvragen, crasht een handvol applicaties. Op dat moment kunnen we gewoon hetzelfde verzoek herhalen om de applicaties gemakkelijk te verwijderen.

24. Voorkom onveilige omleidingen

TL; DR: omleidingen die gebruikersinvoer niet valideren, kunnen aanvallers in staat stellen phishing-scams te starten, gebruikersreferenties te stelen en andere kwaadaardige acties uit te voeren.

Anders: als een aanvaller ontdekt dat u externe, door de gebruiker geleverde invoer niet valideert, kan hij misbruik maken van dit beveiligingslek door speciaal vervaardigde links op forums, sociale media en andere openbare plaatsen te plaatsen zodat gebruikers erop kunnen klikken.

Lees meer: ​​Voorkom onveilige omleidingen

25. Vermijd het publiceren van geheimen in het npm-register

TL; DR: Er moeten voorzorgsmaatregelen worden genomen om het risico te voorkomen dat ze per ongeluk geheimen publiceren voor openbare npm-registers. Een .npmignore-bestand kan worden gebruikt om specifieke bestanden of mappen op de zwarte lijst te zetten, of de bestandsarray in package.json kan als witte lijst fungeren.

Anders: de API-sleutels, wachtwoorden of andere geheimen van uw project staan ​​open voor misbruik door iedereen die ze tegenkomt, wat kan leiden tot financieel verlies, nabootsing van identiteit en andere risico's.

Lees meer: ​​publiceer geen geheimen

Waardeer de moeite? Geef ons project een ster op GitHub

26. Een lijst van 40 generieke beveiligingsadviezen (niet specifiek Node.js-gerelateerd)

De volgende opsommingstekens zijn bekende en belangrijke beveiligingsmaatregelen die in elke toepassing moeten worden toegepast. Omdat ze niet noodzakelijkerwijs gerelateerd zijn aan Node.js en op dezelfde manier worden geïmplementeerd ongeacht het toepassingsraamwerk, nemen we ze hier op als een bijlage. De items zijn gegroepeerd op basis van hun OWASP-classificatie. Een steekproef bevat de volgende punten:

  • MFA / 2FA vereist voor rootaccount
  • Draai wachtwoorden en toegangstoetsen regelmatig, inclusief SSH-sleutels
  • Gebruik een sterk wachtwoordbeleid, zowel voor ops als in-applicatie gebruikersbeheer, zie OWASP wachtwoordaanbeveling
  • Verzend of implementeer niet met standaardreferenties, met name voor beheerders
  • Gebruik alleen standaard authenticatiemethoden zoals OAuth, OpenID, etc. - vermijd basisauthenticatie
  • Beperkingssnelheid voor autorisatie: meer dan X inlogpogingen (inclusief wachtwoordherstel, enz.) In een periode van Y minuten niet toestaan
  • Laat de gebruiker bij een mislukte aanmelding niet weten of de verificatie van de gebruikersnaam of het wachtwoord is mislukt. Retourneer gewoon een algemene verificatiefout
  • Overweeg het gebruik van een gecentraliseerd gebruikersbeheersysteem om te voorkomen dat meerdere medewerkers per medewerker worden beheerd (bijv. GitHub, AWS, Jenkins, enz.) En om te profiteren van een getest systeem voor gebruikersbeheer

De volledige lijst met 40 generieke beveiligingsadviezen is te vinden in de officiële Node.js-lijst met best practices!

Lees meer: ​​40 Generiek beveiligingsadvies

Andere goede leest:

  • Node.js productie best practices - Yoni Goldberg
  • Node.js Beveiligingsoverzicht - Gergely Nemeth
  • Best practices voor snelle beveiliging - Express officieel
  • YouTube: A Node.js Security Roadmap - Mike Samuel

Auteurs - over ons

  • Yoni Goldberg - Node.js consultant, voor klanten in de VS, Europa en Israël
  • Kyle Martin - Full Stack Developer gevestigd in Nieuw-Zeeland
  • Bruno Scheufler - Full-stack webontwikkelaar en enthousiast van Node.js
Waardeer de moeite? Onderaan klappen (tot 50 keer) kan onze dag goedmaken