Preventing Form/Table Access on FE (1 Viewer)

naa123

New member
Joined
Oct 30, 2023
Messages
20
Hi there,

I have created an Access database which will be used to collect client data from practitioners. I have split the database into a front end and back end. On the front end, I have encrypted the file into a ACCDE file, hidden the ribbon, and the navigation bar to try and prevent users from accessing design view/VBA and tables. I am wondering if there is anything more I can do to restrict access to the forms and tables? I want to do all I can to prevent practitioners from seeing data they have not entered.

I do currently have a security system, whereby each user is assigned a TempUserID at log in. This then ensures that when accesssing forms or reports through my form menus, the user can only retrieve data that they have entered. However, there is the risk that the practitioner could see data not entered by them if they access tables.

If anyone has any advice on securing the database further I would really appreciate it.

Thank you!
 
@isladogs is the source for this
 
I was going to say if the data is highly sensitive then perhaps consider encrypting them.
 
We all know that if you hold the shift key down then the start-up form and other settings don't work, and you can get to table data. However, what you can do as well is disable the Shift key at start-up. I do this for my back ends as well and add a start-up form which basically says Go Away!

As I can't paste links yet just look up 'How to enforce or disable the start-up options in an Access database' on Microsoft.
 
Last edited:
My article in the link given in post #2 also covers disabling the shift bypass

However, for reference, the MS article on enabling / disabling the shift bypass is at
Enforce or disable startup options in database - Microsoft 365 Apps | Microsoft Learn

What the article neglects to mention is that the shift bypass can be re-enabled externally. The code to do so is widely available.
Unfortunately, it isn't possible to prevent this.

What you can do as a developer is mitigate the effects of anyone who does re-enable the shift bypass to circumvent app security.
I have two other articles that cover this issue:

1. Open Database with Shift Bypass using Code (isladogs.co.uk) - 3 pages - especially see page 3

2. Lock Down Database Objects (isladogs.co.uk)
 
What you can do as a developer is mitigate the effects ....

Is the nub of the matter !! As your linked articles point out it all depends on your user base and the criticality of the App.

You do what you think needs doing! Security doesn't need to be perfect nor even simply good - it needs to be good enough for the task in hand.

And , of course, security professionals never get this wrong do they!

I'm lucky - these days my user base is just me and the wife: I think I trust me and she-who-must-be-obeyed ain't interested.
 
Last edited:
Interesting... DickyP, are you an H. Rider Haggard fan or did you just like that old Ursula Andress movie?
 
Interesting... DickyP, are you an H. Rider Haggard fan or did you just like that old Ursula Andress movie?
Yes to both, but it is just a common expression in UK. Same as 'her indoors' or 'trouble and strife'.
 
Saddest thing about this whole stream is that until Access 2007 the necessary security was built into Access!
 
@naa123

If you have an accde then users already can't see or modify a form's design. The only issue is preventing access to the database navigator (tables and queries), so your issue should be rather less difficult.
 
Saddest thing about this whole stream is that until Access 2007 the necessary security was built into Access!
Sort of. The process was so arcane that way too many people completely failed to secure their apps or managed to secure everything:) I also wish MS had elected to clean it up and make it easier to understand rather than dumping it.

Since most of us create bespoke software, our customers/employers paid for it so they own it. This means we need to protect the app from being accidentally broken but we don't need to worry about someone stealing intellectual property. We protect the data with SQL Server rather than keeping critical data in an .accdb. Some of us create software that we sell to multiple clients. This requires more security which is why @isladogs has written extensively on the topic. MS could have helped us with this but they elected not to so we are on our own.
 
Sort of. The process was so arcane that way too many people completely failed to secure their apps or managed to secure everything:) I also wish MS had elected to clean it up and make it easier to understand rather than dumping it.

Since most of us create bespoke software, our customers/employers paid for it so they own it. This means we need to protect the app from being accidentally broken but we don't need to worry about someone stealing intellectual property. We protect the data with SQL Server rather than keeping critical data in an .accdb. Some of us create software that we sell to multiple clients. This requires more security which is why @isladogs has written extensively on the topic. MS could have helped us with this but they elected not to so we are on our own.

Your description of what needs doing and how is spot on, however, I truly disagree with your description of Access security. It was simple and easy to use if you started with a proper usage/access plan and it worked well.
 
I truly disagree with your description of Access security. It was simple and easy to use if you started with a proper usage/access plan and it worked well.
That just means that you understood how the feature worked. Working as a consultant, I got to see way too many failed attempts. It's been gone for 17 years so I don't even remember all the ways there were to mess it up.
 
As you say my post does not really help to address the actual problem posed by the thread - just a bit of fond nostalgia. When I was building systems 'for real' the security plan was always in the system specification long before any detailed design let alone coding took place.
 

Users who are viewing this thread

Top Bottom