The developers of kiwitrees regard security as an extremely important part of its development and have made every attempt to ensure your data is safe.
The area most at risk of intrusion would be the /data folder that contains your config.ini.php file, and various temporary files. If you are concerned there may be a risk there is a very simple test you can do: try to fetch config.ini.php by typing http:// url to your site /data/config.ini.php in your web browser.
The most likely result is an “access denied” message like this:
This indicates that the protection built into kiwitrees is working, and no further action is required.
In the unlikely event you do fetch the file (you will just see a semicolon), then that protection is not working on your site and you should take some further action.
If your server runs PHP in CGI mode, then change the permission of the /data directory to 700 instead of 777. This will block access to the httpd process, while still allowing access to PHP scripts.
This will work for perhaps 99% of all users. Only the remaining 1% should consider the most complex solution, moving the /data/ directory out of accessible web space. (Note: In many shared hosting environments this is not an option anyway.)
If you do find it necessary, following is an example of the process required:
If your home directory is something like /home/username,
and the root directory for your web site is /home/username/public_html,
and you have installed kiwitrees in the public_html/kiwitrees directory,
then you would create a new data folder in your home directory at the same level as your public_html directory, such as /home/username/private/data, and place your GEDCOM (family tree) file there.
Then change the Data file directory setting on the Admin –> Site Administration page from the default data/ to the new location /home/username/private/data
You will have two data directories:
Kiwitrees supports https access. If your website is configured with mandatory or optional https support kiwitrees will operate correctly in either mode.
If your website is configured with optional https support, kiwitrees can be configured to switch to https at login. To enable https at login, set the Login URL setting on the Admin –> Site Administration –> Configuration page to your https login URL, which is often in the form https://example.com/admin.php (substitute your domain for example.com). Warning: misconfiguration can disable your login links. If this occurs, access the login by typing the correct URL directly into your browser’s address input.
Before you even start to consider these issues, ensure that your server, whether your own or a web hosts, has good server level protections to prevent unwanted attacks by the many hundreds of spammers and hackers trawling the internet every second of every day looking for gaps in website defences. The following features of kiwitrees can enhance server-level protections, but NOT replace them.
With that out of the way, lets now look at the definitions of “spamming” and “hacking”:
Spamming is the use of messaging systems to send an unsolicited message (spam), especially advertising, as well as sending messages repeatedly on the same site.
Computer hacking refers to the practice of modifying or altering computer software and hardware to accomplish a goal that is considered to be outside of the creator’s original objective.
Ref: Cyber law
So, it is clear from these definitions that the primary place to protect against hacking is your web server. So talk to your web host if you are unsure how that is configured. But kiwitrees does also play an important role. Its code is designed to protect your site from intrusion via the software. Using industry standard methodologies, and (reasonable) restrictions on you and your user’s abilities to accidentally provide routes into your system for hackers. The majority of this is in the code, and cannot be modified or configured by you. However, there is the Administration > Site administration > Site access rules page to help in this battle. This can be used to limit access from a range of IP addresses and “user-agent strings”. More information on this complex tool is available at the FAQ for that page.
Spam attacks are generally more annoying (intensely) than dangerous, although you shouldn’t underestimate their risk. Their major source is through kiwitrees itself, via either (or both) your new user registration page, or your “contact” page.