GDPR is about personal privacy protection, so, as long as you cannot protect sufficiently personal data stored in SQLite, you should consider using MVDB with a MySQL database with all securities around the server as a solution to be GDPR compliant if you use it to store personal and private data. There is still the possibility to write parameterized statements using SQLite, look for prepared statement for SQLite, everything is in the method you use to code your application, you are the only one to be responsible for the safety of the data. MVDB is a framework to manipulate data, you should maybe read more about SQLite and MySQL to present something to auditors. If you use a lot of scripts, then you should read about Delphi to implement security in your SQL statements. Anyway, you can still try to inject the database to be sure!! Now, if the auditors are not able to read your script to detect possible SQL injection, then they should do another job, I don't know... blowing dust from server fans for example
Funny (the last part about doing another job) but irrelevant to the auditors. It's not just about personal data, it's about a security check.
GDPR means also privacy by design, which includes the development environement in our case. MVD uses not a complete delphi environement but a delphi script environement with limited delphi functionallity. When we would use RAD Studio or Lazarus or CodeTyphoon the situation would be clear for the audit. The application developer must use the unrestricted functionality accordingly.
The Delphi script is seen very clearly by the auditors. The manufacturer determines which safety functions are included or not. What is not listed in the documentation is not included and not possible.
The internal audit was in preperation for an official audit. We can close here. Audit has been finished at Aug. 31.
As far as I can tell, the following was criticized during the audit:
- "Compiled" scripts can be reverse engineered relatively easily because they are not binary compiled or encrypted but as a compressed script.
- Passwords in the scipts for database encryption are stored openly and not encrypted. So worthless because easy to read.
- The included RC5 encryption is faulty (conversion Ansi / UTF problem) and therefore cannot be used.
- Delivery with SQLite library without encryption.
- MySQL with full encrypted data storage is only possible in the enterprise version, not in the community. The note in the selection of the database engine is missing here (We don't use MySQL often so I can't confirm. Our other database servers have encryption included).
Besides, the auditors can read the scripts and recommend a 1: 1 implementation in RAD Studio or CodeTyphoon.