Security for the applications we build and run — controls written into the code, verifiable from the outside, with no certifications we do not hold.
The work covers application security and privacy engineering: headers and content policy, rate limiting, checks that default to closed, secret encryption, logs that cannot be rewritten, data anonymisation, and retention periods put into code, not only into a policy. We are not certified auditors and we do not issue certificates.
Construit dejaAm ales „livrat” pentru un domeniu deliberat îngust, iar limita o scriem înaintea listei de capabilități. Controalele descrise mai jos rulează în sisteme proprii și o parte se pot verifica din exterior chiar acum: limitarea de rată se demonstrează cu douăsprezece cereri consecutive (a zecea primește 429, verificat pe producție la 06.09.2026), sonda de sănătate întoarce doar valori logice, iar antetele de securitate se citesc din răspuns. A doua și a treia implementare citate sunt platforma de sesizări — politică de conținut cu valoare unică per răspuns, listă albă de destinații de rețea verificată în integrarea continuă, autentificare în doi pași obligatorie pentru personal — și clientul de semnătură electronică scris fără nicio dependență nouă, cu apărare împotriva încadrării semnăturii XML. Ce NU susține dovada: nu avem nicio certificare, nu facem testare ofensivă ca serviciu, nu operăm un centru de monitorizare și nu emitem atestate de conformitate.
Cele mai multe găuri pe care le-am găsit în propriile sisteme n-au fost exploatări sofisticate. Au fost valori implicite. O rută care iniția un apel telefonic către orice număr, fără autentificare, pe care nicio componentă din interfață nu o mai apela de mult. O verificare de origine care trecea când lista era goală. O adresă IP completă trimisă într-un mesaj de notificare, în timp ce pagina publică promitea anonimizare. Toate trei erau scrise în codul nostru și niciuna nu s-ar fi văzut într-un scaner automat.
De aici vine forma serviciului. Nu vindem un raport de scanare. Citim codul cu o întrebare precisă: când verificarea asta nu poate decide, ce face — permite sau refuză? Poziția implicită e diferența dintre o poartă și o decorațiune. În sistemele noastre, poarta de consum întoarce „nepermis” la excepție, iar ruta de apel telefonic răspunde 404 dacă secretul nu e configurat — adică funcția e oprită dacă cineva nu a pornit-o deliberat.
A doua jumătate a lucrării e ingineria confidențialității, pentru că în practică cele două nu se separă. Termenul de păstrare declarat public nu înseamnă nimic dacă nu e aplicat de cod. La noi, jurnalul de solicitări șterge fișierele mai vechi decât termenul declarat, cu numărul de zile luat din aceeași valoare care apare în politica publicată. Într-un alt sistem, tabela de retenție ține alături de fiecare termen textul publicat, cuvânt cu cuvânt, și temeiul legal — ca politica și baza de date să nu poată devia una de alta în tăcere.
Ce publicăm despre noi înșine e parte din metodă. Politica de conținut a acestui site permite `unsafe-inline` și `unsafe-eval` în scripturi. E o slăbiciune reală și o scriem aici, nu într-un raport intern — a fost chiar mecanismul prin care propriul nostru audit de accesibilitate a putut injecta un instrument de verificare direct în pagina de producție. Un furnizor care nu-și publică propriile slăbiciuni cunoscute nu are cum să le găsească pe ale tale.
What it covers
The work, piece by piece
Citim poziția implicită a fiecărei verificări
Întrebarea centrală a analizei: când verificarea nu poate decide, permite sau refuză? Exemplu real, din propriul cod, marcat ca atare: lista de origini permise a unui widget lasă verificarea să treacă dacă lista e goală — alegere deliberată de compatibilitate cu instalările vechi, scrisă în comentariu, dar care înseamnă că restricționarea pe domeniu trebuie configurată explicit la fiecare implementare. Contraexemplul: poarta de consum care la orice excepție întoarce „nepermis”.
Limitare de rată corectă în spatele unui proxy
Zece cereri pe minut per adresă, cu o subtilitate care decide dacă limita funcționează sau nu: cheia se ia din ultimul salt al antetului de redirecționare, nu din primul. Proxy-ul nostru adaugă adresa reală la sfârșitul a ce a trimis clientul, deci prima intrare e controlată de atacator — cine cheia pe ea își poate depăși limita trimițând valori aleatoare. Se poate verifica din exterior: douăsprezece cereri consecutive dau nouă răspunsuri reușite, apoi 429.
Antete și politică de conținut, cu valoare unică per răspuns unde se poate
Pe acest site: transport strict pe doi ani cu subdomenii și înscriere în lista de precarcare, tip de conținut nedeductibil, politică de referință restrânsă, politică de permisiuni care închide camera și lasă microfonul și localizarea doar pentru pagina proprie. Pe platforma de sesizări, mai strict: politica de conținut primește o valoare unică la fiecare răspuns, generată în proxy, fără surse terțe pentru scripturi, conexiuni sau fonturi, iar încadrarea în cadru e refuzată complet.
Listă albă de destinații de rețea, verificată automat
Într-un proiect public, ce adrese are voie aplicația să contacteze e o listă verificată de o comandă rulată în integrarea continuă, atât static cât și la execuție. Un pachet nou care începe să sune acasă cade la verificare, nu în producție. E controlul care prinde exact clasa de incidente din lanțul de aprovizionare de care nimeni nu se protejează cu un scaner de vulnerabilități.
Secretele nu ajung în răspunsuri, jurnale sau notificări
Sonda de sănătate a formularului de contact întoarce doar valori logice — dacă e configurat, dacă acreditarea e validă, dacă jurnalul se poate scrie — niciodată tokenul, identificatorul de conversație sau numele botului. Tokenurile de canal ale platformei de mesagerie se păstrează criptate. Jurnalele de alertă trec printr-un modul de redactare a datelor personale înainte de scriere.
Anonimizare aplicată înainte de scriere, nu după
Adresa IP se trunchiază la prefixul de rețea — /24 pentru IPv4, /48 pentru IPv6 — înainte de a intra în jurnal sau într-o notificare. Cu două detalii care contează: se ia ultimul salt, nu primul, din același motiv ca la limitarea de rată; și adresele IPv4 raportate în formă mapată IPv6 se recunosc și se tratează ca IPv4, altfel ar fi păstrate întregi, adică exact pe dos față de scop.
Jurnal care adaugă, nu rescrie
Solicitările prin formular se scriu într-un jurnal cu adăugare, un obiect pe linie, cu drepturi 0600 pe fișier și 0700 pe director, înainte de a se încerca livrarea. Motivul e o defecțiune reală: când canalul de notificare a picat, endpointul întorcea 500 și fiecare solicitare se pierdea fără urmă. Acum un canal stricat înseamnă „trebuie să ne uităm în fișier”, nu „cererea n-a existat niciodată”. Rezultatul livrării se scrie ca a doua linie, cu același identificator.
Termenul de păstrare aplicat de cod, nu doar declarat
Jurnalul de solicitări șterge fișierele mai vechi decât termenul declarat public, cu numărul de zile luat din aceeași valoare. Într-un alt sistem, tabela de retenție ține lângă fiecare termen textul publicat cuvânt cu cuvânt și temeiul legal, iar funcția de curățare raportează implicit ce ar șterge; ștergerea reală cere un argument explicit. Ștergerea în tăcere e un mod de eșec, nu o funcție.
Identitatea și semnătura, când proiectul le cere
Avem scrise, de la zero și fără dependențe noi, un furnizor de servicii pentru autentificare federată și un client pentru semnătură electronică. Analizorul de XML nu procesează definiții de tip de document, deci clasa de atacuri pe entități externe nu se aplică; verificarea de semnătură întoarce nodul acoperit de semnătură, nu o valoare logică, iar apelantul e obligat să compare identitatea obiectului — apărarea împotriva încadrării semnăturii. Canonicalizarea a fost verificată pe vectorii oficiali ai specificației.
What it looks like
The route, step by step.
01
Stabilim domeniul și ce nu avem voie să atingem
În scris, înainte de orice comandă: ce sisteme, ce perioadă, ce tipuri de verificare sunt permise și cine e persoana de contact dacă ceva se oprește. Livrăm: documentul de domeniu semnat și lista sistemelor excluse.
02
Citim codul și configurația, cu accent pe poziția implicită
Verificările care nu pot decide, secretele care ajung în răspunsuri sau jurnale, rutele care nu mai sunt apelate de nimeni dar rămân deschise, antetele lipsă. Livrăm: constatările cu fișier și linie, ordonate după ce se poate face cu ele, nu după severitatea teoretică.
03
Reparăm sau descriem exact reparația
Unde avem acces, punem controlul și scriem testul care îl ține pe loc — o verificare care nu are test se pierde la prima refactorizare. Unde nu avem acces, livrăm modificarea descrisă suficient de precis încât echipa clientului să o poată aplica fără să ne mai întrebe.
04
Legăm confidențialitatea de cod
Termenul de păstrare, anonimizarea și lista destinatarilor devin valori în cod, cu textul publicat alături. Livrăm: registrul de prelucrări completat, cu coloana „unde e implementat” plină, și lista punctelor rămase de decis, cu cine decide fiecare.
05
Verificăm din exterior ce se poate verifica din exterior
Antetele, comportamentul la limită, ce întorc sondele de sănătate. Livrăm: comenzile exacte de verificare, ca oricine — inclusiv un auditor al clientului — să poată repeta verificarea fără noi.
Straturile pe care le atingem, de sus în jos
Datele
What we touch, where it lives, and how long it stays
The questions anyone with a data protection officer asks — asked here before they do.
Ce atingem într-o analiză
Codul, configurația de server, antetele răspunsurilor și, unde e cazul, schema bazei de date și politicile de acces pe rând. Nu avem nevoie de datele reale ale clienților ca să facem analiza și preferăm să nu le atingem deloc.
Ce nu facem fără domeniu autorizat în scris
Nicio acțiune care produce trafic împotriva unui sistem în funcțiune. Verificările pe producție care apar în această pagină sunt cereri obișnuite de citire, pe sisteme proprii. Orice depășire a acestei limite cere o autorizare scrisă, cu perioadă și adrese, semnată de cine are dreptul să o dea.
Unde ajung constatările
Într-un document cu o constatare pe rând: unde e, ce se poate face cu ea, ce anume o remediază și cum se verifică remedierea. Constatările care descriu o cale de exploatare nu circulă prin canale nesecurizate și nu ajung în materiale publice înainte de reparație.
Registrul de prelucrări
Pentru partea de confidențialitate, rezultatul e un registru cu un rând pe activitate: scop, temei, categorii de date, destinatari, transferuri, locația stocării, termen, măsuri și fișierul din cod unde e implementat. Ce nu s-a putut verifica se scrie „neverificat”, nu se completează din șablon.
Regula care ține politica lipită de cod
Dacă o modificare de cod schimbă ce se colectează, cui ajunge sau cât se păstrează, politica publicată se modifică în același pas de livrare. Divergența dintre politica publicată și cod a fost exact problema care ne-a făcut să scriem registrul propriu.
A case
A forgotten route that could call anyone
Situația
Într-o revizie a propriului site am dat peste o rută de interfață de programare care iniția un apel telefonic către orice număr trimis în corpul cererii. Fără autentificare, pe costul și de pe numărul firmei. Nicio componentă din interfață nu o mai apela — singurul apelant era un element care nu se mai afișa. Adică funcționase deschisă către internet fără ca nimeni să aibă motiv să se uite la ea.
Ce am construit
Am tratat-o ca pe două probleme, nu una. Tehnic: ruta cere acum un secret partajat într-un antet, iar dacă secretul nu e deloc configurat răspunde 404 — capabilitatea e oprită dacă cineva nu o pornește deliberat, nu pornită până o oprește cineva. Juridic și etic: un apel automat nesolicitat e o prelucrare de date pe care persoana apelată n-a cerut-o, deci am scris în registru ce ar fi necesar pentru o eventuală reactivare — temei documentat față de apelat, evidența consimțământului și un canal de opoziție.
Ce a ieșit
Capabilitatea e închisă implicit și rămâne închisă până când cineva ia o decizie explicită. Rândul din registrul de prelucrări descrie starea, ce era înainte, riscul și condițiile de reactivare — deci următoarea persoană care găsește ruta nu trebuie să reconstruiască raționamentul.
Ce nu spune cazul
Nu ne-am dat seama de asta printr-un instrument. Am găsit-o citind rutele una câte una și întrebând, pentru fiecare, cine o apelează. Un scaner automat ar fi văzut o rută care întoarce 400 la o cerere goală și ar fi trecut mai departe. E și limita metodei: acoperă ce citim, iar ce nu citim rămâne neacoperit — de aceea domeniul se stabilește în scris.
Întrebări
What people ask us before they call
Aveți certificări de securitate?
Nu. Nici ISO 27001, nici SOC 2, nici o certificare de testare ofensivă, nici acreditare de auditor. Nu emitem certificate și nu semnăm atestate de conformitate. Ce putem arăta e practica proprie, cu fișier și linie, și controalele pe care le-am pus în sisteme aflate în funcțiune. Dacă îți trebuie un certificat pentru un dosar, îți trebuie un organism acreditat, nu noi — și e mai bine să afli asta acum.
Faceți teste de penetrare?
Nu ca serviciu. Nu avem echipă de testare ofensivă, licență sau metodologie certificată, și nu ne prefacem că avem. Ce facem e analiză a codului și a configurației, plus verificări neinvazive din exterior — antete, comportamentul la limita de rată, ce scurg răspunsurile de eroare. Dacă proiectul cere testare ofensivă adevărată, îți trebuie o firmă specializată; putem lucra alături de ea pe partea de remediere.
Ce ați găsit în propriile voastre sisteme?
Trei lucruri, într-o singură zi de analiză, toate scrise public în registrul nostru. O rută care iniția un apel telefonic către orice număr din corpul cererii, anonim, fără autentificare, pe care nicio componentă din interfață nu o mai apela — acum răspunde 404 dacă secretul nu e configurat, adică e oprită dacă cineva n-o pornește deliberat. Un widget de conversație care se încărca la fiecare vizualizare și scria sesiunea în memoria browserului înainte ca vizitatorul să ceară ceva — acum se încarcă la apăsarea butonului. Și adresa IP completă trimisă într-o notificare, în timp ce pagina publică promitea anonimizare — acum se trunchiază înainte de scriere.
Politica voastră de conținut permite `unsafe-eval`. De ce ar trebui să vă cred?
Pentru că v-am spus noi, nu ați aflat voi. Da, politica acestui site permite `unsafe-inline` și `unsafe-eval` în scripturi — e o slăbiciune reală, moștenită din felul în care sunt încărcate anumite scripturi terțe, și e chiar mecanismul prin care propriul nostru audit de accesibilitate a injectat un instrument de verificare în pagina de producție. Pe un proiect unde constrângerea o punem noi de la început, forma corectă e cea din platforma de sesizări: valoare unică per răspuns generată în proxy și nicio sursă terță pentru scripturi. Diferența dintre cele două e exact discuția pe care ar trebui să o avem la începutul unui proiect, nu la sfârșit.
Cum verific eu, fără să vă cred pe cuvânt, că limitarea de rată funcționează?
Trimițând douăsprezece cereri consecutive către o rută de interfață de programare a acestui site și numărând răspunsurile: primele nouă trec, a zecea primește 429 cu antetul care spune peste cât timp se poate reîncerca. Fereastra e de un minut. Comanda e în lista de surse a acestei pagini și o poți rula acum. Același principiu îl aplicăm la ce livrăm: dacă un control nu se poate verifica din exterior de către client, nu e livrat, e declarat.
Ce se întâmplă cu datele personale dintr-un formular?
Se scriu într-un jurnal cu adăugare, un obiect pe linie, cu drepturi restrânse pe fișier și director, înainte de a se încerca livrarea — ca un canal de notificare stricat să nu facă cererea să dispară. Adresa IP e trunchiată la prefixul de rețea înainte de scriere. Fișierele mai vechi decât termenul declarat se șterg, cu numărul de zile luat din aceeași valoare care apare în politica publicată. Iar rândul din registrul de prelucrări spune, pentru fiecare element, în ce fișier din cod e implementat.
Puteți face autentificare cu identitate electronică de stat sau semnătură electronică?
Codul există și e testat, dar nu e activat nicăieri în producție, iar diferența contează. Avem scris un furnizor de servicii pentru autentificare federată și un client de semnătură, ambele fără dependențe noi, cu apărările specifice implementate și cu teste. Ce lipsește nu ține de cod: contract cu autoritatea, certificat de sistem și înregistrarea adresei de producție. Până atunci, varianta care funcționează azi e cea în care cetățeanul semnează pe portalul oficial și încarcă documentul semnat înapoi.
Ce controale puneți în mod normal într-o aplicație nouă?
Antete și politică de conținut cu valoare unică per răspuns; limitare de rată cu cheia luată corect din spatele proxy-ului; separare pe organizație aplicată în bază, nu doar în aplicație; secrete criptate și niciodată în răspunsuri sau jurnale; chei de idempotență pe evenimentele de la terți; autentificare în doi pași obligatorie pentru conturile de personal; jurnal de audit cu vizibilitate separată pentru intern și public; și, pentru proiectele publice, o listă albă de destinații de rețea verificată automat la fiecare livrare.
Ce nu acoperă acest serviciu?
Securitatea rețelei corporative, echipamentele utilizatorilor, monitorizare continuă de tip centru de operațiuni, răspuns la incident 24/7, investigație criminalistică și instruirea împotriva phishingului. Nu sunt lucruri pe care le facem prost — sunt lucruri pe care nu le facem. Domeniul nostru e aplicația pe care o construim sau o preluăm, plus datele care trec prin ea.
Pe ce se sprijină fiecare afirmație de mai sus (24 surse)
Limitare de rată la 10 cereri pe minut, cu fereastră de 60 de secunde, aplicată doar pe rutele de interfață de programaremiddleware.ts:8-9 (valori), 45 (domeniu), 78 (selector /api/:path*)
Cheia limitării se ia din ultimul salt al antetului de redirecționare, nu din primul, pentru că proxy-ul adaugă adresa reală la sfârșit — prima intrare e controlată de clientmiddleware.ts:12-19
Antete pe producție: transport strict 63072000 s cu subdomenii și precarcare, tip de conținut nedeductibil, politică de referință restrânsă, politică de permisiuni care închide camera; încadrarea în cadru e refuzată complet pe rutele de interfață de programare și limitată la aceeași origine pe paginihttps://www.megapromoting.com/api/health/contact · 2026-09-06
Politica de conținut a acestui site permite `unsafe-inline` și `unsafe-eval` în scripturi — slăbiciune cunoscută, publicată de noi; a fost mecanismul prin care auditul propriu de accesibilitate a injectat un instrument de verificare în producțieaccesibilitate-performanta.md:secțiunea „Instrumente și metodă”, rândul despre axe-core
Sonda de sănătate a formularului întoarce doar valori logice, niciodată tokenul, identificatorul de conversație sau numele botuluiroute.ts:4-12 (motivul), 48-56 (corpul răspunsului)
Jurnal cu adăugare pentru solicitări, un obiect pe linie, fișier 0600 și director 0700, scris înainte de încercarea de livrare; rezultatul livrării se scrie ca a doua linie cu același identificatorlead-store.ts:4-17 (motivul), 51-57 (drepturi), 94-112 (linia de livrare)
Termenul de păstrare aplicat de cod: fișierele mai vechi decât termenul declarat public se șterg, cu numărul de zile luat din aceeași valoare care apare în politicălead-store.ts:22-28 (motivul și temeiul), 59-76 (curățarea)
Anonimizarea adresei IP la /24 pentru IPv4 și /48 pentru IPv6, aplicată înainte de scriere; se ia ultimul salt, iar adresele IPv4 în formă mapată IPv6 se recunosc, altfel ar rămâne întregilead-store.ts:125-150
Ruta de apel telefonic ieșit era deschisă anonim către internet și nu era apelată de nicio componentă activă; acum cere un secret partajat și răspunde 404 dacă secretul nu e configuratroute.ts:5-18 (descrierea problemei), 22-27 (poarta)
Registru de prelucrări cu un rând pe activitate, coloană „unde e implementat” și marcaj explicit „neverificat” unde nu s-a putut confirma; regula ca politica publicată și codul să se modifice în același pasregistru-prelucrari.md:secțiunile 1-5 și „Cum se menține acest registru”
Widgetul de conversație se încărca la fiecare vizualizare și scria sesiunea în memoria browserului înainte ca vizitatorul să ceară ceva; acum se încarcă la apăsarea butonuluiregistru-prelucrari.md:secțiunea 2, nota „Remediat 2026-09-06”
Politică de conținut cu valoare unică per răspuns, generată în proxy, fără surse terțe pentru scripturi, conexiuni sau fonturi; încadrarea în cadru refuzată; transportul strict lăsat deliberat pe terminatorul TLSnext.config.ts:6-30:src/proxy.ts:22-35,97; src/lib/security/csp.ts:96-102
Listă albă de destinații de rețea verificată în integrarea continuă, static și la execuțiepackage.json:15-16 (check:egress, check:egress:runtime)
Tabela de retenție ține lângă fiecare termen textul publicat cuvânt cu cuvânt și temeiul legal; funcția de curățare raportează implicit, ștergerea reală cere argument explicit0024_retention_and_data_rights.sql:26-28 (raportează implicit), 171-205 (termenele și textele)
Jurnal de audit cu vizibilitate separată intern/public, actor și rol0001_initial_schema.sql:274-283
Autentificare în doi pași obligatorie pentru conturile de personal; întărirea drepturilor pe funcțiile din bază; poziția „închis” la nesiguranța media:supabase/migrations/0027_function_acl_hardening.sql; 0004_media_safety_fail_closed.sql
Analizor XML fără procesarea definițiilor de tip de document; verificarea de semnătură întoarce nodul acoperit, nu o valoare logică, iar apelantul compară identitatea obiectului — apărare împotriva încadrării semnăturii; canonicalizare verificată pe vectorii oficiali ai specificațieiREADME.md:35-49; implementare în protocol.ts, xml.ts, dsig.ts, fără dependențe noi
Identificatorul personal nu se stochează niciodată în clar, ci doar ca amprentă cu sareREADME.md:10-15
Testul implicit verifică tocmai că starea dezactivată nu scurge nimicmpass.spec.ts:6-20
Contraexemplu de poziție implicită „închis”: poarta de consum întoarce „nepermis” la orice excepțieindex.ts:177
Modul de redactare a datelor personale aplicat înainte de scrierea alerteloralerting.ts:6 (safe-log)
Exemplu de verificare cu poziție implicită „deschis”, documentat ca atare în cod: lista de origini permise a unui widget lasă verificarea să treacă dacă e goalăwidget.routes.js:190-205
Tokenul de canal se păstrează criptat, cu revenire la text simplu doar pentru înregistrările vechiwhatsapp.service.js:1-44
Citările interne arată numele fișierului și linia. Calea completă rămâne în depozitul nostru; o putem parcurge împreună, la cerere.