ABCpdf is a component presenting an API, much like .NET
Like .NET there are no restrictions on what you can do with the
API. If you call File.Delete it will delete a file. That is what
the API does.
It is not difficult to make your use of the APIs secure, but you
have to actively do it. You need to be making design decisions
Each system is different and each system has different needs,
however the following are the base principles by which you should
operate when securing a system using ABCpdf.
You are in control. You call into ABCpdf. You decide what APIs
to use. You decide which parts you deploy. You decide the
environment in which it operates. You are in control here and the
majority of choices are going to be made by you - not by
Defense in depth is key. One impenetrable barrier is not enough.
You want a series of barriers. If one is breached the others will
hold. Layers are what keep you safe.
ABCpdf contains architectural structures which provide defense
in depth. Most are internal and are not visible from outside. Some
- such as our FireShield technology - are visible and
Most of the defensive layers will come from you because there is
a limited amount we can restrict without impacting your ability to
use the software.
Evaluate security before you start to write code. Then review
your evaluation as your code and architecture develops.
Do not trust your users
Attacks can only occur if attackers can provide input to a
system. The obvious route in, is via a standard method supplied to
Once this route is compromised an attacker can experiment with
various inputs to see how they can manipulate your systems.
Stack overflow exploits, SQL injection and cross site scripting
are just some of the many exploits which are based on insufficient
input vetting of user input.
You need to be suspicious of the data that is provided to you.
Vet it first and make sure it is good before passing it to
If you store data, consider encrypting it so that a breach will
not result in data loss. If encryption is too complex or dangerous,
even just a level of obfuscation will add a significant
ABCpdf will do its own vetting too, but you know much better
than it, what it is that you consider to be acceptable.
Vetting Inputs. How should input data be validated or
Every application is different and every situation needs
evaluation but there are some obvious factors which one should bear
in mind. At minimum you need to ensure that your inputs and outputs
are not excessively large or numerous.
ABCpdf will do its best to accommodate your requests, so if you
ask it to do something excessive it will do its best to do so. At
that point it becomes a matter related to the OS as to whether it
is allowed the resources to do this or not. Better to decide these
things yourself rather than leave them up to chance.
For example, if you allow your users to upload TIFF images,
consider if it would be reasonable for them to upload a 1TB image.
If you allow users to render a PDF, consider if it would be
reasonable to allow them to select 72,000 dpi as the target
resolution (producing a 500 Gigapixel output). If they are allowed
to provide a description for an item in an invoice, should they be
allowed to provide the text of Moby Dick?
Do not trust your code
ABCpdf is designed to run from a reduced permission
Take advantage of this. Ensure that your code runs in a process
as a low privilege user with access only to the resources that it
Where ABCpdf offers further layers of protection, take advantage
of them. Use technologies like FireShield to further restrict
access and add layers of protection.
ABCpdf is modular so if you do not need a particular module then
consider eliminating it. You deploy ABCpdf and you can decide which
pieces should be deployed.
Read the documentation for the functions you use and ensure you
take note of any security relevant details. If security is
mentioned in the documentation it is for good reason.
Do not trust yourself
Many of us have blind spots to our failings and there is no more
obvious place for this than when we write code.
Users find bugs that developers had never dreamed of. Developers
have a rather myopic view of what might happen and how things will
The reality is that the code you write will be flawed and you
are not the best person to judge the ways in which it is
You need to submit your code for review by a third party. A
third party can be someone else in your team, or for especially
sensitive situations you might consider employing a penetration
You should do team-based threat assessments based on the
architecture of your systems. Consider the access points and think
about how these might expose attackable surfaces.
Automate as much as possible to reduce the possibility that
human error may creep in. A complex manual deployment is bound to
go wrong sooner or later. Automate to eliminate.
Do not trust your machine
You need perimeter security on your host machine. Most obviously
this comes from a firewall and anti-virus software.
Do also consider if other technologies might be appropriate,
perhaps at the network level.
Simple and Secure
Try and keep things simple. It is much easier to secure a system
with one access point than it is a system with ten.
The simpler your systems, the simpler it will be to:
- see if they are designed well and correctly
- assess any threats they may be vulnerable to
- know if something goes wrong