AxiomNode Lab

Student-led engineering team building open-source tools, security-focused software, and practical digital products.

نبني أدوات مفتوحة المصدر ومنتجات تقنية حقيقية من خلال العمل الجماعي والتعلّم بالتطبيق.

AxiomNode Lab is a student-led technology team focused on learning through real engineering work. We take ideas from problem definition to implementation, testing, documentation, release, and maintenance.

A zero-runtime-dependency security SDK for Node.js and TypeScript services.

It brings together practical backend security building blocks including API keys, webhook verification and replay protection, secure cookies, CSRF/CORS controls, defensive HTTP headers, SSRF-oriented URL checks, rate limiting, secret-safe logging, environment validation, a SARIF-capable secret scanner, and Express/Fastify/Hono/Redis adapters.

npm install @axiomnode-lab/guard

We prefer focused, documented controls with explicit security boundaries over broad “secure by default” claims.

Imed Kablavi Co-Founder

Alaa Madi Co-Founder

GitHub only shows organization membership publicly when each member chooses Public membership. The complete visible roster is available on the organization People page.

1. Start from a real problem and define a useful scope.
2. Build the smallest version that can be tested honestly.
3. Use branches, pull requests, reviews, and CI instead of treating main as a scratchpad.
4. Add negative tests and failure-mode coverage for security-sensitive behavior.
5. Document what a feature does and what it does not guarantee.
6. Release only after the project has a repeatable build/test path.
7. Keep improving based on evidence, bug reports, and real usage.

• Useful before impressive — features should solve a concrete problem.
• Security claims need evidence — tests and documented boundaries come before marketing language.
• Small dependencies, clear ownership — we avoid unnecessary supply-chain surface where practical.
• Reproducibility matters — CI, versioning, release notes, checksums/provenance where appropriate.
• Contributors should understand the project quickly — readable READMEs, issues, examples, and contribution guidance are part of the product.
• Private while unfinished, public when ready — some work stays private until it is suitable for external use.

Public repositories are open for useful issues, pull requests, testing, documentation improvements, and technical discussion. Students and developers who want hands-on experience are welcome to follow the work and contribute where a repository accepts contributions.

Good first contribution: reproduce a bug, improve a test, clarify documentation, or propose a focused feature with a concrete use case.

Explore repositories · View public members · Open AxiomGuard