@datnamer Genie.jl has been built with security in mind from day one. Some of the most important features in this regard are:
- active measures against SQL injection built into
SearchLight's query builder - use the provided types,
SQLColumn to wrap user input and have it properly escaped before sending it to the SQL server. Even if you don’t use this wrapping explicitly, the query builder will do it for you, eliminating the risk of rookie mistakes like interpolating
POST vars directly into SQL query strings.
- a robust routing system that optionally supports type annotation and makes it difficult to exploit routing vulnerabilities.
- strongly typed model fields (that, for example, won’t allow using SQL injection
Strings instead of other types).
- custom model validators that won’t persist the data unless it complies with logical (and optionally
Cookies by default.
- explicit argument and return types for 99.9% of the functions in the core codebase, which makes it impossible to invoke methods with different argument types or return different types.
- the fact that Julia is a compiled language - script injection is impossible as in production, the app once started does not get reloaded, so injected code would not be picked up.
- the same goes for
Flax.jl view templates which are also compiled.
- no direct access to
POST variables - they are made available through the
@params() collection which can be sanitized (sanitization not happening right now as it’s a bad idea to do it by default, as seasoned web developers probably remember PHP’s
magic_quotes fiasco – but it might be interesting to have a
hook that would automatically trigger custom data sanitization rules if available).
- same goes for
Session variables - access to them is provided through
helpers that could sanitize the data.
At this moment, the single most important missing feature that I can think about, in terms of both security and developer happiness is a
form helper that would know how to render
That being said though, the codebase has not been audited explicitly for security vulnerabilities. Also, the project is very young, with very limited production usage. So if you ask me if the code is 100% secure (or bug-free in regards to security), based on my experience with other technologies, I’d say “probably not”.
You simply can’t compare Genie v0.7 with Django or Rails or Phoenix or any other framework that’s been in production for years, supported by thousands of contributors and tens of thousands of hours of development time. And that goes for security, bugs, performance and features. Let’s be realistic about it.
To conclude, if you’re thinking about developing security critical and performance critical products today with Genie.jl or any other beta software stack for that matter, my advice is obviously not to. Not only Genie, but Julia itself is still beta.
But if you have a side-project or you work on a lightweight web app MVP for your startup and you want to turn it into something fun, exciting and rewarding and can spare a few hours to contribute to Genie.jl by reporting and fixing bugs or adding new features, then by all means, yes, Genie would be great for that!
Even the longest journey starts with a first step. Django was once beta software too, with just a handful of contributors. It’s up to us to make Genie equally safe and feature rich. And eventually better, I’m sure, considering Genie’s unique strength: it’s built with Julia, which makes it easy to write performant and safe code!